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La presente invention conceme un systdme de consultation et /ou mise jour de 
serveurs DNS (Domain Name System) et/ou d^annuaires LDAP (Lightweight 
Directory Access Protocol) k partir d'un tenninal. La presente invention permet 
notamment ^ un abonne, a partir d'xm terminal quelconque, de consulter et de mettre 
5 a jour un enregistrement de ressources de telecommunication stocke dans un serveur 
DNS ou LDAP- 

Les serveurs DNS (et LDAP) sont utilises dans le monde informatique pour 
nommer des machines (par exemple: association d'une URL v/eb a une adresse IP 
correspondant au serveur web hebergeant ce site web). Ces serveurs sont 
10 habituellement consult^s par des machines informatiques au moyen d'un logiciel 
commun^ment appele RESOLVER, disponible dans la plupart des terminaux ou 
serveurs informatiques. Ce logiciel permet d'extraire une information d*un serveur 
DNS en r^ponse a la requSte d'xm client Cette information pent etre disponible 
directement aupr&s du premier serveur DNS consult^ ou bien aupres d'un serveur; 

15 DNS r6^renc^ par le premier, et ainsi de suite si n^cessaire par indirections! 
successives. Les contenus des serveurs DNS sont mis k jour par des sp6cialiste^^ 
"administrateur" et de manidre peu frequente (mise k jour de fichiers k plat sousf 
plateforme UNDC ou application d6di£e via IHM sous les plate-formes serveurs" 
Windows). Le format des contenus des serveurs et des requStes sont d^futus dans unl 

20 protocole, dit protocole DNS decrit dans les docimients RFC 1034 et RFC 1035; 
disponibles sur le site web de TIETF (www.ietf org). 

D'autre part, les serveurs DNS sont desormais appeles a jouer un role dans le 
cadre du service ENUM visant k oflGrir aux abonnes une portability g^neralis^e de 
numero de telephone. Ce service ENUM utilise le syst6me de nmnerotation 

25 telephonique international d^fini par lUIT sous la recommandation E.164. Plus 
prScis^ment, le service El^JUM permet a tout abonne disposant d'une numero 
telephonique unique E.164 (numero de telephone de type +33296053859) d'etre joint 
par dif^rents moyens en fonction de ses prejKrences configur6es dans xm profil 
h6berg6 dans le r6seau par un serveur DNS. Par exen:q)le, le numero de tel^hone 

30 unique E.164 de Tabonne ENUM pent 6tre associ6 k im numSro de t616phone mobile 
(+33686166924), a un num6ro de telephone fixe (+33296916404), k une adresse 
eMail fbertrand.dupont@rd ifrancetelecom.com\ k une URL de site web 
(httpi/ywww.bertrand.du pont.com) . k un numero de t616phone VoIP 
(sip:bertrand.dupont@sip.fi'ancetelecom.com), 4 unnxmi^ro de fex, etc. 
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L'ensemble de oes infonnations peuvent etre stock^es dans un serveur DNS 
standard et acc€d€es seton le moddle de d616gation hi^rarchique repr&ente en Fig. 1 . 

L»acces se fait par un serveur DNS racine (E164,ARPA). Chaque pays dispose 
cncuit c d'xin c od e ta^phonign e im^q"" Q"^ p"""^ T?ran ceX.et-un-se rvgnr DNS est p.fxf. 
5 au niveau 1 par chaque pays (3.3.E164.ARPA pour la France). Des operateurs de 
t€16comn»jnications ou des foumisseurs de services ENUM gerent enfin des serveurs 
DNS (indique en Fig. 1 par DNS 1 h DNS 6) en fonction des ressources t^lephoniques 
(tranche de num^ros t616phoniques E.164) qui levir sent attributes. Le module retenu 
est un decoupage par tranches: 5 tranches de numtros de telephone fixes RTC avec 
10 des prefixes aUant de 1 a 5 et une tranche de numtros de telephone mobile identifite 
par le pr6fixe 6. 

A vai numero de telephone au format E.164, est associe un chemin dans 
I'arborescence des serveurs DNS. Plus precistent, chaque numero de t616phone au 
fonnat international E.164 est invers6, le code est supprim6, un pomt est ajoutt 

15 entre chaque chififre et le rtsultat obtenu est accoK au domaine el64.arpa de mani^ k 
transformer le num6ro de t616phone en un nom de domaine Internet unique. Par 
exemple, le numi&o de t6tephone +33686166924 donne ^r^s transformation, le nom 
de domaine Internet 4.2.9.6.6.1. 6.8.6.3 .3.el64.aipa. 

D'autre part, a chaque numSro de t^ldphone au format E.164 est associt un 

20 enregBtrement comprenant un ou des enregistrements de ressources (Resource Record 
ou RR), stocks dans le serveur de niveau 2 coirespondant, chaque enregistrement de 
ressource pouvant conoprendie im ou plusieurs champs. Par exemple, a un numtro de 
t6tephone au format E.164 peuvent gtre associe des enregistrements de ressource 
NAPTR (Naming Authority PoinTeR), tels que dtfinis dans les documents RFC 2915 

25 et RFC 2916, disponibles sur le site de I'lETF. De maniere sch6matique, un 
enregistrement de ressource NAPTR indique un service de t616commumcation (n" de 
tel, fax, adresse eMail, site web etc.) associe un niveau de priorite. On appellera par 
la suite enregistrement ENUM (ou profil ENUM) un ensemble d'enregistrements 
NAPTR associes a un nom de domaine Internet. Par exemple, si le profil ENUM 

30 suivant est stock6 dans un serveur DNS de niveau 2 : 

$ORIGIN9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

INNAPTRIOOIO'V "teH-E2U" "!^*$!tel:+33296053859!" 
INNAPTRlOOll "u" "tel+E2U" "!a *$ltel:+33296916404!" 
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INNAPTR10012 "u" "teI+E2U" "!^*$!tel:+33686166924! 
INNAPTR 100 13 "u" "sip+E2U" "!^*$!sip:bdupont@sip.ftr<Lfi:!" 
INNAPTR12010 'V "maflto+E2U" "!^*$!mail2:bdupont@rdflrAfr!" . 
IN NAPTR 130 10 'V "http+E2U" "^^*$!http://www.bdupontfr!" 

5 

La ligne d*en-tete indique un nom de domaine Internet correspondant au numero 
de telephone EJ64. Le logiciel RESOLVER permet a partir du nom de domaine 
d'acceder a renregistrement. A chaque enregistrement NAPTR de Texemple ci- 
dessus correspond une ressource ou service de telecommunication. Deux champs 
10 numeriques suivent le temie « NAPTR », il s'agit respectivement des priorites de 
service: "Ordre" et ''Preference". Plus la vaieur du champ "Ordre" est faible, plus le 
service est prioritaire et si plusieurs services ont im niveau d'ordre ideirtique, plus la 
vaieur de Pr^lKrence assocife est feible, plus le service est prioritaire. Ainsi, les Kgnes 
de I'enregistrement d-dessus correspondent k des priorites d^croissantes. 
15 La 1^ ligne correspond au service telephonique fixe 0296053859 avec uri' 

ordre=l 00 et une preference =1 0. : 
La 2^ ligne correspond au service telephonique fixe 0296916404 avec mi^ 
ordre=l 00 et une preference^l 1 . 

La 3^ ligne correspond au service telephonique mobile 0686166924 avec un*^ 
20 ordre=100 et une preference=12 . 

La 4^^ ligne correspond au service telephonique IP via SIP vers I'adresse SIP 
bdupontfglsip.ftrd.fi- avec un ordre=100 et une preference=13 . 

La 5*"^ ligne correspond au service de courrier electronique eMail dont Tadresse 
de destination est bdupont@rd.ftrd.fr avec xai ordre=120 et une preference=10 . 
25 Enfin, la 6™^ ligne correispond au service web dont TURL d'acc^s est 

http://www.bdupont.fr avec un ordre=130 et ime preference=10 . 

La signification de cet enregistrement est la suivante. Si Ton cherche a joindre le 
numero de telephone E.164 (+33296053859), le logiciel RESOLVER transmet une 
requ6te au serveur DNS niveau 2 avec le nom de domaine Internet correspondant 
30 (9.5.8.3.5.0»6,9.2.3.3.el64.arpa), En retour, le serveur DNS niveau 2 (DNS2) foumira 
dans la r^ponse la liste des ressources de telecommunication (^galement denommes 
ci-aprds services) associ6s au num6ro de telephone +33296053859, telle que donne 
par renregistrement. Le logiciel RESOLVER et le service ENUM pourront alors 
exploiter tout ou partie de ces ressources en mode s^quentiel (le syst6me tentera de 
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joindre le service le plus prioritaire puis, en I'absence de r6ponse ou en cas 
d'occupadon, le systfeme essaiera de joindre le service de moindie priorite, etc.) ou en 
mode diffijsion 0& service ENUM tentera alors de joindre amultanement I'ensemble 
-des-s©R4e©^.- 



La modification des profils ENUM dans un serveur DNS s'accommode mal du 
proc6d6 de mise k jour par administrateur tel que connu de I'^at de la technique. En 
effet, au contraire des noms de domaines Internet, les services classiques de 
telecommunication tels que le telephone ou la t61ecopie sont susceptibles de 
modification frequente. Qui plus est, il est quelquefois necessaire de programmer ces 
10 modifications de manidre automatique sur une base quotidienne voire horaire. D est 
alors extrdmement diflScile pour des raisons de dispombilite et de flexibiBt6 de feire 
supporter la modification de configuration d'un profil ENUM k son propre op6rateur 
de telecommunications ou k son foumisseur de service ENUM 

Un probieme particuUer k la base de I'invention est de permettre k un abonne 
15 une consultation et/ou une modification an^le et rapide de son profil ENUM stocke 
dans un serveur DNS ou un annuaire IX>AP. 

De maniere plus generale, le probl&ne k la base de I'invention est de permettre 
une consultation et/ou modification ample et rapide d'un ou de phisieurs 
enregistrement(s) de ressouice stock^s) dans un serveur DNS ou LDAP et ce, k partir 
20 d'un terminal convraitionnel quelconque. 

Le probl&ne a la base de I'invention est resolu par un systeme de consultation 
et/ou de nrise k jour d'un eniegistrement stocke dans une premiere base de donnees, 
ledit enregistrement comprenant un ou une pIuraHte d'enregistrements de ressources, 
ladite premiere base de donnees etant hebergee par un serveur de noms de domaine, 
25 dit serveur DNS, ou un serveur d'annuaire, dit serveur LDAP, pouvant etre accede par 
indirection k partir d'un serveur DNS, ledit systeme comprenant: 

- des moyens de communication pennettant audit systeme de recevoir d'un 
terminal de telecommunication une demande de consultation et/ou de modification 
dudit enregistrement ou une programmation d'une telle demande ; 
30 - des moyens de contrSle adaptes k determiner i partir de ladite demande de 

consultation et/ou de modification transmise au dit systeme ou prealablement 
programmee dans ledit systeme. un nom de domaine et une operation a effectuer sur 
ledit enre^strement ; 
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- des moyens de gestion de protocole adaptes a rechercher a partir dudit nom de . 
domaine, Tadresse IP dudit serveur h^bergeant ladite premiere base de dorm6es et, en 
fbnctioii de ladite operation, k transmettre au dit serveur une requete de lecture ou de 
mise ^ jour dudit enregistrement, 
5 Avantageusement, ledit syst^e comprend des moyens d'authentification 

adaptes a autlientijBer au niveau applicatif P6metteur de ladite demande a partir 
d'informations d'authentification stockees dans une seconde base de donn^es locale 
ou distante, 

Lorsque Temetteur de ladite demande a 6X6 authentrfie, lesdits moyens de 
10 gestion de protocole permettent de transmettre une requete en consultation selon le 
protocole DNS (DNS Query) audit serveur DNS, la requSte ayant pour argument ledit 
nom de doraaine, et k recevoir une premiere reponse dudit serveur* 

Selon un mode de r^sation, les moyens de contrdle sont adaptes k determiner 
ledit nom de domaine k partir d*un identifiant d'abonn6 qui pourra 6tre le num^ro 
15 tdKphonique E, 164 dudit abonne. 

Les moyens de contrdle sont alors adaptes k extraire des informations et a 
d^erminer en fonction de ladite demande une operation k efifectuer sur un 
enregistrement de ressource de type NAPTR. 

Selon d^autres modes de realisation les moyens de contrdle sont adapt^s^^ 
20 extraire des informations et k determiner en fonction de ladite demande une operation 
k efEectuer sur im ou plusieurs enregistrements de ressource de type A, NS, MD, MF, 
CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO,MX, TXT. 

Les caracteristiques de Tinvention mentionnees ci-dessus, ainsi que d'autres, 
25 apparaftront plus clairement k la lecture de la description suivante d*un exemple de 
realisation, ladite description etant feite en relation avec les dessins joints, parmi 
lesquels : 

la Fig. 1 illustre schematiquement le modele de delegation utilise dans le service 
ENUM; 

30 la Fig. 2A illustre schematiquement un exomplc d'environnement du systfeme 

selon I'invention; 

la Fig. 2B iUustre schematiquement renvironnement de la Fig. 2A dans ie 
contexte du service ENUM ; 
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la Fig- 3A repr&ente le schema de principe du syst6me de consultation/ mise k 
jotur selon Tinvention ; 

la Fig. 3B represente un exemple de syst^me de consultation/ mise a jour selon 

Irffiv cntion - ; 

5 la Fig. 4 represente schematiquement une procedure de consultation et mise a 

jour manuelle d'un profil ENUM avec accds en mode vocal ; 

la Fig- 5 represente schematiquement une procedure de consultation et mise k 
jour manuelle d'un profil ENUM par envoi de messages SMS ; 

la Fig. 6 reprdsente schematiquement une procedure de consultation et mise a 
1 0 jour manuelle d'un profil ENUM par le Web ; 

la Fig. 7 represente schematiquement une procedure de consultation et mise a 
jour manuelle d'un profil ENUM a partir d'un Minitel; 

la Fig. 8 represente schematiquement une procedure de consultation et mise k 
jour manuelle d'un profil ENUM par eMail; 
15 la Fig. 9 represente schematiquement une procedure de consultation et mise k 

jour manuelle d'un profil ENUM par lUU a partir d'un terminal RNIS; 

la Fig. 10 represente schematiquement une procedure de programmation de mise 
automatique de profil ENUM ; 

la Fig. 11 rq)resente schematiquement une procedure de mise a jour 
20 automatique de profil ENUM; 

la Fig. 12 represente schematiquement une procedure de consultation de profil 
ENUM lorsque ce dernier est stocke dans un annuaire LDAP ; 

la Fig. 13 represente schematiquement une procedure de mise k jour de profil 
ENUM lorsque ce dernier est stocke dans un annuaire LDAP. 

25 

La Figure 2A iflustre im exemple d'environnement du systeme selon Tinvention. 

Des foumisseurs de service de gestion de ressources de telecommunication, ci- 
apres denoimnes foumisseurs de service, ont etc schematiquement representes en 
30i,...,30n. Chaque foumisseur de service dispose d'un serveur DNS (310 ou LDAP 
30 (34i) hebergeant une base de donnees et plus generalement de plusieurs serveurs 
redondants de raaniere k augmenter la fiabilite de I'acces au service. La base de 
donnees contient un enregistrement des ressources de teidcommuriication pour tous les 
abonnes du foumisseur de service en questioiL 
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Le systdme (50) selon rinvention peut etre connecte d*une part au r^seau 
t61€phonique public via une interfitce standard de type analogique ou num6rique TO ou 
T2 et, d'autre part, au r^eau IP via une interi^ce standard de type Ethernet. 

Plus precisement^ le systeme (50) est connecte au r^seau Internet si la pr6sente 
5 invention est accessible a tout abound, quel que soit son foumisseur de service, et 
pourra etre connecte k un reseau Intranet si la presente invention est accessible aux 
seuls abonnes d'un foumisseur de service, 

Le systeme (50) pourra etre accede par un terminal telephonique RNIS (2) 
connecte soit directement soit a travers un PABX (3) au reseau RNIS (10). On 
10 rappelle que le reseau RNIS est interconnect^ nativement au reseau RTC, 

Le systdme (50) pourra aussi dtre accede par un terminal telephonique classique 
(4) ou un temiinal Minitel (5) connect^ au reseau RTC (1 1). 

Le ^teme (50) pourra encore Stre acc€d6 par un terminal mobile GSM (6) 7 ou 
encore un temnnal UMTS non represents (les r6seaux GSM et UTRAN sont 
1 5 interconnectes nativement au reseau RTC). 

Le sj^tdme (50) pourra gtre acc^6 au moyen d'un terminal telephonique IP (7) 
connects au r6seau IP (13)* 

Le systeme (50) pourra enfin etre accSd6 au moyen d'un noicro-ordinateur (8) 
relie au rSseau IP soit au travers une interface Ethernet (rSseau local d'entreprise) soit 
20 par modem (RTC/RNIS/ADSL/cable/satellite etc.) 

L'aboime pourra en outre recevoir des notifications du systdme (50) grSce k Tun 
des terminaux envisages ci-dessus ou bien encore k Taide d'lm terminal &x (9). 

La Figure 2B illustre un exemple d'environnement du systeme selon Tinvention, 
25 dans le contexte d'lm service ENUM. Les Elements portant les memes num6ros de 
reference sont identiques a ceux de la Fig. 2A. 

On a indiqu6 en 40 le serveur DNS ENUM de niveau 0 (racine), Ce serveur 
dispose de Tensemble des adresses IP referen9ant Tensemble des servexirs DNS 
ENUM de niveau 1, correspondant aux codes des differents pays (33 pour la France, 
30 34 pour TEspagne, 44 pour TAngleterre, etc.). Par exemple, on a ^ figurer en 41 le 
serveur DNS ENUM de niveau 1 correspondant k la France. 

Chaque op^rateur ou foumisseur de service ENLTM dispose d'au moiris un 
premier serveur DNS ENUM de niveau 2 (31|), dit serveur primaire, redond6 par au 
moins un second serveur DNS ENUM de niveau 2 (31*0, dit serveur secondaire, ce 
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afin d'assurer une bonne fiabilit^ de service. Le serveur primaire (resp. secondaire) 
heberge une base de donntes 33i (resp. 33'i). Dans chaque serveur de niveau 2, est 
stocks, pour chaque nmnero de t^ldphone E.164 d'abonn6 au service ENUM, un profil 

'. eeapos6--des— ^Sw«Htes--4«ss©»«es— de-4^icoffimumcatioHh^^ 

5 ressoiucce conespondant ^ un moyen d*acc6s (par ex. t^l^phone fixe bureau, t^Kphone 
fixe domicile, tdephone mobile, t^l6plione IP, adresse eMail du bureau, adresse eMail 
du mobile, N** de fex professionnel, etc.) ainsi que les priorites aflKrentes a chacun de 
ces moyens d'acces. Chaque ressoiux:e de tel&xjmmunication est declaree au moyen 
d'un enregistrement de lessource NAPTR comme on I'a vu plus haut. La priorite 
10 d'une ressource est determin^e par le contenu des champs Ordre et Preference de 
r enregistrement de ressource NAPTR, tels que definis dans le document RFC 2915 de 
I'lETF et exen^^lifies dans la partie introductive. 

Un foumisseur A de service ENUM (30i) peut egalement disposer d'un serveur 
15 LDAP (340 h^bergeant un annuaire dynamique LDAP (360 tel que d6fini dans le 
document RFC 1959 de FIETF. L'int^rfit de cette configuration est de permettre de 
g6rer les profils ENUM par indirection non plus dans le DNS ENUM niveau 2 mais 
dans I'annuaiie djmamique LDAP. L'avantage procure consiste k ne plus modifier le 
profil du client ENUM au niveau du serveur DNS ENUM niveau 2 mais directement 
20 dans I'annuaire LDAP qui, lui, est con9U pour stocker des profils dynamiques. Dans ce 
cas, le DNS ENUM niveau 2 (310 contient par exemple le profil suivant pour 
I'ensemble des numdios de telephone E.164 commen9ant par le pr6fixe "+332": 



$ORIGIN 2.3.3 .el 64.arpa. 
25 INNAPTRlOOlO "u" "ldap+E2U" 

"r.+332(.*)$ !klap;//ldap.founiisseurA.fi^/cnF01 !" 

L'annuaire LDAP (360 est accede par indirection a partir du serveur DNS 
ENUM de niveau 2 et contient les enregistrements de ressource pour les difF6rents 
30 abounds du foumisseur A. 

Un serveur ou une passerelle ENUM (80) peut consulter un foumisseur de 
service ENUM (300 pour connaitre la liste des ressources de t616communication d*un 
abound ENUM. Pour ce feire, le logiciel RESOLVER transforme le mun6ro unique 
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E.164 de raboime en aom de domaine comme on Ta vu plus haut et accede par 
indirections successives au serveur DNS ENUM niveau 2 (31,) et, le cas ^cheant, 
aprte indirection suppl^mentaire au serveur LDAP (34i). Le foumisseur de service 
retoume la liste des ressources de Tabonne en question avec les priorites associees. Le 
5 serveur ou la passerelle ENUM (80) peut alors, selon le cas, tenter de joindre 1' abonne 
en utilisant successivement les ressources, par ordre d^croissant de priorite ou joindre 
rabonn6 au moyen de Tensemble de ses ressources. 

La Fig. 3A represente le schema de principe du systeme (50) de mise a jour 
10 selon rinvention . 

Le systdme comprend des moyens de communication (1150) permettant k \m 
abonne de dialoguer avec ledit systdme et notamment : 

de transmettre k Taboim^ une requgte en authentification ; 
15 - de recevoor dudit abonne des informations permettant son 

authentijGication ; 

de recevoir dudit abonn6 une demande de modification d'un 
em:egistrement (dite demande manuelle) ou une demande de 
modification automatique (dite demande programm^e) en fonction d'un 
20 crit&re ten5)orel ou g^ographique ; 

de transmettre le contenu d'un enregistrement prealablement ou 
posterieurement a la demande de modification ; 

de transmettre au dit abonne une notification de confirmation de mise k 
jour lorsque la modification demand^e a bien 6t6 ejQTectufeet 
25 d'infirmation de mise ^ jour lorsque cette demiere n'a pu etre eJBfectu6e; 

de transmettre au dit abonne, a fin de consultation ou revision, une 
demande de modification automatique prealablement enregistr^e dans 
ledit systeme ; 

de transmettre au dit abonn6 im historique des modifications eflfectuees. 

30 

Le syst^e comprend 6galement des moyens d^inter&ce (1160) permettant de 
connecter lesdits moyens de communication au r6seau RTC/RNIS et/ou k un rdseau IP 
(Internet ou Intranet). 
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25 



Le systSme comprend encore des moyens d'authentification (1173) coop^rant 
avec les moyens de conununication pour authentifier au niveau applicatif un emetteur 
de demande de consultation et/ou mise k jour. L'authentification au niveau applicatif 



terminaL Les moyens d'authentification utilisent pour ce feire des informations 
d'authentification stockees dans une base de doim6es (1 170) locale ou distante . 

Outre les informations susmentioimees, la base de donnees (1170) peut 
notamment contenir des programmes de modification automatique relattfe k differents 
abonnes, les adresses IP des serveurs des difiKrents foumisseurs de gestion de 
ressources de telecommunication, les historiques de modifications manuelles ou 
automatiques des enregistrements, les adresses auxquelles les notifications de 
confimiation/infimiation de naise ^ jour doivent etre transmises. 

Le systeme (50) comprend ^core des moyens de gestion de protocole (1162) 
assurant entres autres la fonction RESOLVER. En particulier les moyens de gestion 
de protocole sont adapt^s k rechercher, le cas echeant par indirections successivea, le 
contenu d'un enregistremetit de ressource (RR) a Faide d'un nom de domaine. Les 
moyens de gestion de protocole peuvent transmettre k cette fin des requites de 
consultation selon le protocole DNS (DNS Query). En outre, les moyens de gestion 
de protocole peuvent mettre k jour des enregistrements de ressources k partir de 
requStes de mise k jour (DNS Update). Selon un mode de realisation, si des 
enregistrements de ressources sont stockees dans un annuaire LDAP, les moyens de 
gestion de protocole permettront egalement la consultation d'un enregistrement dans 
un annuaire LDAP (emission d'une requete LDAP Search) ainsi que la mise a jour de 
cet enregistrement (Emission d'xme requete LDAP Modify). Lorsque la mise a jour a 
ete r^alisee, les moyens de protocole re9oivent un acquittement du serveur du 
foumisseur de gestion de ressources de telecommunication. 

Les moyens de contr6Ie 1 175 coordonnent les moyens pr6cit6s et notamment : 




ordonnent aux moy 
en authentification ; 



^^ens de conununication la transmission d'une requSte 
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aprds authentification de I'abonii6 par les moyens d'autheirtification 
(1173) den^dent aux moyens de protocole (1162) de transmettre une 
requite en consultation^ fonnatent la rSponse et la retransmettait sous 
forme intelligible a Tabonn^ via les moyens de communication; 
5 - k partir d'lme demande en modffication d'un enregistrement de ressource 

par un abonne, determinent une operation h eflfectuer sur ledit 
enregistrement et im identifant de Tabonne 

sur r^eption de confirmation/infirmation de mise a jour par les moyens 
de protocole, notifient la confirniation/lnfiurmation a Tabonne via les 
10 moyens de communication. 



La Fig. 3B illustre un exemple de realisation de Tinvention dans le contexte 
d'un service ENUM. 

Les elements portant les mSmes num6ros de reference sont identiques k ceux de 

15 la Fig. 2A. En particulier, l'abonn6 pourra contacter le systfeme de mise k jour (50) au 
moyen de Tim des termiaaux envisages plus baut. En (30) a €t6 repr&ent6 un 
foumisseur de service de gestion de ressources de teMconmiunication comprenant un 
serveur DNS de niveau 2 (31), dit serveur primaire, redond^ par un serveur secondaire 
(non repr6sent6). Le serveur (31) comporte une base de doimSes (33) et une pile ae 

20 protocole DNS (32) integrant les protocoles DNS d^crits dans les docunaents RFC 
1034 et RFC 1035. La pile de protocole integre ^galement les protocoles DNS decrits 
dans les documents RFC 2136 et RFC 2137 destines a permettre la mise a jour (DNS 
Update) d'un enregistrement de ressource (RR). De mani^re optionelle, le fbumissexir 
de service de gestion de ressources comprend aussi un serveur d'annuaire LDAP (34) 

25 hebergeant \me base de donnees (36). Le serveur d'annuaire LDAP comporte ime pile 
de protocole LDAP (35)- 

Les moyens de coinraunication du systeme (50) sont constitues des modules 
suivants : 

30 o im module ayant en cbarge le traitement des appels teI6phoniques 

entrants et sortants (52). Ce module gfere Fetablissement et la liberation 
de la conrniunic-ation ; 
o un module (53) de gestion d'Loformation dTJsager a Usager (lUU) 
permettant d'extraire et de transmettre des informations lUU ; 
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o im module (54) de traitement des codes DTMF. Ce module a en charge 

la recuperation des DTMF saisis par Tabonne ; 

o un module (55) de synthese vocale ; 

o un module (i>6) de drftusion de fichiers vocaux pre-enregistres ei 

5 concat6n6s pour former des phrases ; 

o un serveur videotex (57) ; 

o un module de reception et d'envoi de SMS (58) ; 

o un module d'envoi de fax (59) ; 

o un serveur SMTP (61) pemiettant remission et la reception d'eMail ; 

10 o un serveur Web dyoamique (63). 

II convient de noter que le systdme peut comprendre €galement vn module de 
reconnaissance vocale (non repr&ente) adaptd h reconnaitre une information 
prononcee par raboim6« 

15 Les moyens de communication sont relies a Texterieur au moyen d'une interface 

RTC et/ou RNIS (51) et une interfece IP (60). La premiere est basee sort sur une carte 
analogique RTC multi-port soit sur une carte RMS TO (2 canaux) ou T2 (30 canaux). 
La seconde est une interfece Ethernet, La passerelle indiquee par (14) rappelle que les 
r^seaux RTC/RMS et IP sont nativement interconnect^s en protocole VOIP 

20 (H323/SIP). 

Le systeme (50) comporte, comme precedemment, des moyens 
d'authentiiication (73) autorisant Tautfaentification applicative des abonnes du service 
k partir d'infonnations d'authentification, par exemple des coxiples de pseudonymes 
(Loginjd) et de mots de passe stockes dans une base de donn6es (70) locale ou 
25 distante. En outre, la base de donn^ comprend les identifiants des diff^rents 
foumisseurs de service ENUM (tel que 30), les adresses IP ou les noms de machine 
des DNS tiers 2, des demandes de modification automatique de profil ENUM, les 
historiques de modification manuelle ou automatique de profils ENUM, les adresses 
de notification de modification du profil ENUM (N° de fex, SMS, eMail). 



30 
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Le systfeme coinpread encore un module de gestion de protocole DNS (62), de 
preference dans sa forme sScuriste (DNSSec). Ce module joue en particuliex le rdle de 
RESOLVER pour la lecture des enregistrements de ressource. 

Le cas ech&nt, un module de gestion de protocole LDAP (64) y est adjoint pour 
5 i>ermettre la lecture et la modification d*enregistrements dans un annuaire LDAP. 

Le sj^feme comprend egalement un module (72) permettant la configuration des 
adresses des serveurs DNS de niveau 2 ainsi qu'im module (71) charge de tenir A jour 
les modifications manuelles ou automatiques des profils ENUM et d'elaborer, le cas 
10 echeant, des statistiques poiur Texploitant du systeme. 

Les moyens de contrdle sont constitu6s, d'une part, d'un module (74) charge de 
la configuration automatique de profils ENUM a partir de demandes de modification 
auton[iatique programmees par des abound et stocks dans la base de donn^ (70) 

15 et, d'autre part, d'un module (75) charg6 de la configuration « manuelle » des profils 
ENUM Ce d«nier gdre des scripts ENUM, notamment un script de lecture de profil 
ENUM (on rappelle qu'un profil ENUM est constitu6 d'une liste d'enregistrements de 
ressource NAPTR), des scnpts de modification des champs des enregistrements de 
ressource NAPTR et notamment des chanqps ordre, pr^rence, service (adresse eMkil, 

20 numero de t^l^hone, adresse eMail etc.). Si Ton souhaite pr^voir la consultation 
et/ou la mise k jour d'enregistrements de ressource DNS autres que NAPTR, des 
scripts suppl^mentaires doivent etre prevus pour leur modification. 

La Fig. 4 illustre sch6nmtiquement une procedure de consultation et de 
25 modification manuelle d*un profil ENUM en mode vocal via vai telephone fixe ou 
mobile de type RTC, RNIS, GSM ou IP. 

L'abomi6 ENUM 6met a I'etape 100 un appel telephonique gratuit (type nxunSro 
vert) ou payant selon un mode de remuneration g^ographique ou forfeitaire de type 
audiotel ou numeros color6s depuis un terminal fixe RTC (4) ou RNIS (2) connect^ 
30 sur le reseau public ou derriere im PABX (3) ou un terminal mobile (6) de type GSM, 
ou depuis un terminal IP (7) a destination de Tinterfece RTCVRNIS (51) du systhms 
(50). L*automate de traitement d'appel (52) accepte automatiquement I'appel entrant a 
Tetape 101. Le module script ENUM (75) donne a r6tape 102 I'ordre au module de 
synthase vocale (55) ou au module de diSiision de fichiers vocaux (56) de difiiiser k 
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raape 103 vers rabomi6 ENUM une annonce vocale invitant I'abonn^ ENUM a saisir 
son nuin6ro ENUM E.164 ainsi que son pseudonyme et son mot de passe . L'abonn^ 
ENUM saisit k Y&ixpe 104 via son clavier ces informations qui sont vehicul€es dans la 

idc 50UG forme de DTMF et-qui-son<^-j»^*^"'-ftp*«e-'HP «' ' mofln le He trnitement des . 
DTMF (54). Ces informations sont foumies a I'etape 105 au module d'authentification 
(73) qui intertoge la base de donn^es locale ou distante (via par exemple une interfece 
de type ODBC (pour Open DataBase Connectivity)) en operant une recherche sur le 
Numero ENUM E.164. Celle-ci foumit k I'^tape 107 les informations 
d'authentification correspondantes au module d'authentification (73). Ce dernier 
compare le pseudonyme et le mot de passe saisis par le cUent ENUM avec les 
informations d'authentification contenues dans la base de donn^es (70). En cas de 
concordance, le module d'authentification (73) ordonne a I'etape 108 au module de 
synthase vocale (55) ou au module de diffusion de fidiiers vocaiix de diflBiser k 
r^tape 109 vers I'abonn^ ENUM une annonce du type 'Tour consulter votre profil 
15 ENUM taper sur la touche 1, pour modifier les attributs de votre profil taper sur 2, 
pour configurer de mani&re automatique votre profil tapez sur 3, pour modifier votre 
pseudonyme-mot de passe tapez sur 4, pour acc6der a votre journal de modification de 
votre profil tapez 5, etc. Si Fabonn6 ENUM tape sur la touche 1 de son clavier 
tadphonique a I'^ape 110, le code DTMF correpondant est intercepts par le module 
20 de traitement des DTMF (54) et est retransmis k I'ftape 111 vers le module script 
ENUM (75). Le script ENUM (75) d6tecte alors qu'il s'agit d'une commande de 
lecture du profil ENUM. Le script ENUM (75) 6met alors a I'^ape 1 12 une demande 
d'intenogation au module protocole DNS (62) en foumissant en argument I'adresse 
E.164 de I'abonn^ ENUM mise sous forme de domaine (transformation du numero de 
25 t616phone E.164 de type 33296053859 en (9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module 
de gestion de protocole DNS (62) qui joue le rdle classique d'un RESOLVER peut 
d'abord verifier si les informations ne sont pas pr^entes dans son cache suite a une 
consiiltation pr6c6dente ou interroger (k I'etape 1 13) selon le protocole standard DNS 
(requate DNS Query) successivement le serveur DNS de niveau 0, le serveur de DNS 
30 de niveau 1, puis le serveur DNS de niveau 2 par la pile de protocole DNS (32). Pour 
gagner en efficacit6, les donnees d'un enregistrement NAPTR sont charg6es dans la 
mtoire vive du serveur DNS (31). Si Fabonne ENUM est effectivement enregistrfS 
dans le serveur DNS. (31) du fijumisseur de service ENUM (30) alors la pile de 
protocole DNS (32) retoume (k I'etape 114) au module protocole DNS (62) la liste 
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des enregistrements NAPTR correspondsdits. Le module de protocole DNS (62) se 
charge ensuite de les retraiismettre vers le module Script ENUM (75) i T^tape 1 15- Le 
module (75) analyse et interprete les em-egistrements NAPTR et genfere un texte 
comprehensible par Tabonne ENUM du type "Service N^ 1: telephone vers le 
5 0296053859, service N"^: telephone vers le 0686166924, service N'^S: eMail vers 
bertrand.dupont@xd,francetelecom.co]n. etc.). Ce texte est envoye vers le module de 
synthese vocale (55) a Fetape 116 qui se charge de diflSiser cette information a 
Tabonne ENUM a Tetape 117. Dans le cas ou le module de diffiision de fichiers 
vocaux (56) est utilise, le module (75) genere renchamement des fichiers vocaux a 
10 jouer. 

Apres dijQRision de cette information, le module de synthese vocale (55) ou le 
module de diffiision de fichiers vocaux (56) diffiise k nouveau a T^tape 118 ,1a liste 
des operations d*administration possibles sur le profil ENUM "Pour consulter votre 
profil ENUM taper sur la louche 1, pour modifier les attributs de votre profil taper sur 

15 2, pour configurer de maniSre automatique votre profil tapez sur 3, pour modifier 
votre pseudonyme-mot de passe^ tapez sur 4, pour acc6der k votre journal de 
modification de votre profil t^ez sur 5, etc.). • 

Si Pabonn6 ENUM choisit la modification de son profil ENUM k Tdtape 150, 
cette commande est interceptee par le module script ENUM (75) k P^tape 151v3uite k 

20 la detection du code DTMF par le module de traitement DTMF (54). Le systferiie (50) 
entre alors dans xm dialogue iteratif bas6 sur la diJffusion de messages vocaux vers 
rabonn6 ENUM a partir d'un texte genere par le module script ENUM (75) (k Tetape 
152) en fonction du contexte et difiEusds (a I'etape 153) sous forme vocale par le 
module de synthase vocale (55) ou par le module de difiiision de fichiers vocaux 

25 concatenes (56). Ce dernier valide les choix proposes en utilisant son clavier DTMF a 
Tetape 154 et les commandes sont transmises a Tetape 155 vers le script ENUM (75). 
Par exemple, le dialogue vocal pent etre le sxiivant: 

o pour modifier Tordre/preference de vos services tapez sur 1, pour modifier 
30 les attributs d'un sendee tapez 2, pour ajouter un service tapez 3, pour 

supprimer un service tapez 4,etc. 
o ->4 
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pour supprimer le num^ro de t^tephone 0296053859 tapez 1, pour 
supprimer le num6ro de t616phone 0686166924 tapez 2, pour supprimer 
I'adresse eMail hertrand.dunnnt^rd.fran cetelecom.com tapez 3,etc. 

___ 



o Pour valider votre choix tapez 1 , sinon tapez 2 
-> 1 

-> Pour supprimer un service tapez 1, pour enregistrer vos modifications tapez 
2, pour revenir au menu principal tapez sur 0 
-»2 



o 
o 



Lorsque Tabonn^ ENUM demande la prise en compte des modifications du 
profil ENUM, le module script ENUM (75) 6met une requ^e de demande de 
modification a I'^tape 156 vers le module protocole DNS (62). Ce dernier emet une 
commande DNS UPDATE a l'6tape 157 k destination du module protocole DNS (32) 
15 du serveur DNS (31) du foumisseur de service ENUM (30). II est rappeK que 
I'adresse IP de ce dernier est stockfe dans la base de donn&s (70) et qu'eHe est 
rctiouvte k partir du num6ro E.164 de I'abonnfi ENUM. Le module protocole DNS 
(32) met ^ jour I'infoimation dans la m&noire vive du serveur (31) et demande la mise 
k jour de la base de donn^ (33) qm est g&i^ralement un fichier texte k plat, Le 
20 protocole DNS gfere le numfto de modification dans ce fichier de manidre a ce que 
le/les DNS secondaiie(s) puisse(nt) lecharger lui/eux-m6me(s) cette modification k 
des intervalles de temps pi^6finis. La base de donnees (33) confiime la mise k jour k 
r^tape 159, ce qui se traduit par une r^onse a la requdte de demande de l'6tape 160. 
Le script ENUM (75) intercepte a I'^tape 161 le code retour de cette r6ponse puis 
25 g^ndre k I'etape 162 le message de confirmation/lnfirmation de prise en compte de la 
modification. Le module de synthase vocale (55) ou le module de difiiision de fichiers 
vocaux diffuse cette information vers I'abonne ENUM a l'6tape 163. Ce dernier pent 
alors liberer la communication. 

Selon une variante de cette procedure, en reponse aux messages vocaux, 
30 Tabonn^ pent foumir directement une reponse de m?mi6re vocale. C'est alors le 
module de recoimaissance vocale qui daermine le chofac ou rinformation contenue 
danslarenonse. 




La Fig. 5 illustre sch6matiqueinent la procedure de consultation et de 
modification manuelle d'un profii ENUM via Tenvoi de SMS depuis des temunaux 
t^Kphoniques mobile ou fixe de type GSM, RTC, RNIS ou IP. L'abomi6 ENUM 6met 
a r^tape 200 un SMS foraiate (ex: N**E.164 + pseudonyme + mot de passe + requete) 
5 comme specific par le foiimisseur de service ENUM (30) depuis un tenninal fixe RTC 
(4) ou RNIS (2) connecte sur le reseau public ou derridre le PABX (3) ou m temiinal 
mobile (6) de type GSM, ou depuis un tenninal IP (7), k destination du module SMS 
(58) de la presente invention. Ce dernier transmet le SMS a Tetape 201 vers le module 
script ENUM (75). Ces informations sont foumies a I'etape 202 au module 

10 d'authentification (73) qui interroge a T^tape 203 la base de donndes locale ou distante 
(via une interfece ODBC par exemple) en operant une recherche sur le numero 
ENUM E.164. Celle-ci fbumit a I'etape 204 les informations correspondantesi: au 
module d'authentification (73) qui se charge de comparer le pseudonyme et le mo^? de 
passe saisis par le client ENUM dans le SMS avec les informations d^authentificadon 

15 contenues dans la base de donnees* En cas de concordance, le module 
d*authentification (73) ordonne a T^tape 205 au module script ENUM (75) de trailer la 
requSte contenue dans le SMS. Le script ENUM (75) d^tecte qu'il s'agit d'lme 
conomande de lecture du profii ENUM, Par consequents le script ENUM (75) eicnet 
une demande d'interrogation k P^tape 206 au module de gestion protocole DNS (62) 

20 en foumissant en argument Tadresse E.164 de Tabonne ENUM transforoiee s6us 
forme de domarae (transfomiation du numero de telephone E.164 de type 
33296053859 en (9.5.8-3.5,0.6.9.2.3.3,el64.arpa). Le module de gestion protocole 
DNS (62) qui joue le role classique d'un RESOLVER interroge (etape 207) a Taide 
d'\me requgte (DNS Query) le serveur DNS de niveau 0, puis le serveur DNS de 

25 niveau 1, a moins que les inforaiations ne soient deja dans son cache suite a une 
consultation pr6c6dente de ces serveurs. Pour gagner en efficacit^ les donnees d*un 
serveur DNS sont chargees dans la mdmoire vive du serveur (31). Si rabonne ENUM 
est eflFectivement enregistr6 dans le serveur DNS (31) du foumisseur de service 
ENUM (30) alors le module protocole DNS (32) retoume k I'^tape 208 les 

30 enregistrements NAPTR correspondants. Le module de gestion de protocole DNS (62) 
se charge ensuite de les retransmettre vers le module script ENUM (75) a Tetape 209, 
Ce dernier analj^e et interprete les enregistrements NAPTR et genere un texte 
relativement synth6tique et con5>rehensible par Fabonn^ ENUM du type "PI: Tel= 
0296053859, P2: Tel=0686 166924, P3: eMail= 
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hertrandduDontrt7)rd.francetelecom.com . P4: urI=www.bertranddupont.fr, etc.). Ce 
texte est envoy6 k I'^tape 210 vers le module d'eiivoi de SMS (58) qui envoie le SMS 
(k raape 211) vers le tenninal teKphomque a I'origine de la requSte (utilisation du 

ira6ro-dgfap pe laiit); '■ 

5 Uabonnfi ENUM 6msl k 1* et^e 250 un message SMS formate (ex: N** E. 1 64 + 

pseudonyme + mot de passe + type de requ6te^ ECR: Pl:tel=06 86 166924, 
P2:email=bertrand.dupont@rd.francetelecom.com) comme specific par le foumisseur 
de service ENUM (30) depuis un tenninal fixe RTC (4) ou RNIS (2) connect^ sur le 
reseau pubUc ou derri^e le PABX (3) ou un terminal mobile (6) de type GSM, ou 
10 depuis un terminal IP (7) k destination du module SMS (58) de la pr^sente invention. 
Ce dernier transmet le message SMS k I'etape 251 vers le module script ENUM (75). 
Ces informations sont foumies a I'^tape 252 au module d'authentification (73) qui 
interroge a l'6tape 253 la base de donnas locale ou distante (via une interfece ODBC 
par exemple) en operant une recherche sur le num^ ENUM E.164. Cefle-ci foumit k 
15 I'etape 254 les informations correspondantes au module d'authentification (73) qui se 
charge de comparer le pseudonyme et le mot de passe saisis par le client ENUM dans 
le message SMS avec les informations d'authentification contenues dans la base de 
donn^es. En cas de concordance, le module d'authentification (73) en avertit le module 
script ENUM (75) qui traite alors la requ6te contenue dans le SMS. Le script ENUM 
20 (75) d6tecte qu'il s'agit d'une commande de mise k jour du profil ENUM avec des 
arguments. Le script ENUM (75) vdrifie la syntaxe de la commande et, si elle est 
correcte, 6met une demande de mise k jour k I'etape 256 au module de gestion de 
protocole DNS (62). Ce dCTuier 6met une commande DNS UPDATE a I'etape 257 k 
destination du module protocole DNS (32) du serveur DNS (31) du foumisseur de 
25 service ENUM (30). II est rappele que I'adresse IP de ce dernier est stockee dans la 
base de donn^es (70) et qu'elle est retrouv6e k partir du num^ro E.164 de I'abonne 
ENUM. Le module protocole DNS (32) met a jour I'information dans la m^moire vive 
du serveur (31) et demande la mise a jour de la base de dorm^es (33) qui est 
gen^ialeraent un fichier texte k plat. Le protocole DNS gere le numero de 
30 modification dans ce fichier de maniere a ce que le/les serveur(s) DNS secondaire(s) 
puisse(nt) recharger lui/eux-meme(s) cette modification k des intervalles de teiiq>s 
pr€<i6£ms. Le ser/eur (3 1) confirme la mise a jour k Vitspe 259, ce qui se traduit par 
une reponse k la requSte de demande de mise k jour k P^tape 260. Le script ENUM 
(75) intercepte k I'etape 261 le code retour de cette r6ponse puis g&ifere k I'etape 262 
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le message de confbnatioivlnfinnation de prise en compte de k modification avant de 
I'envoyer au modude d'envoi de SMS (58) qui se charge d'envoyer le SMS k V6tape 
263 vers le tenninal t^l^honique d I'origine de la iwjuate (utilisation du num^ro de 
I'appelant). 

5 

La Fig. 6 illustre sch6matiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par le web A partir d'un terminal disposant 
d'lm navigateur web (8). 

L'abonn6 ENUM demande a I'^tape 300 le t^Iechargement de la page web 
10 d'accueil du service de gestion du profil ENUM. Celle-ci est retoum^e k I'etape 301 
par le serveur web (63) de la prdsente invention. Cette page web aflSche un foimulaire 
d'autfaentification k fabonn^ ENUM. Celui d saisit son numdro E.164 puis son 
pseudoixyme et son mot de passe, Ces informations sont tranatnises k I'^tape 302'iau 
serveur web (63) qui lui m^me les transmet k Vetape 303 au module d'authentification 
15 (73). Le module d'authentification (73) interroge k Tetape 304 la base de donnas 
locale ou distante (\da une inter&ce ODBC par exemple) en operant ime recherche sur 
le nnm&o ENUM E.164. Celle-ci foumit k V&ape 305 les infonnations 
correqwndantes au module d'authentification (73) qui se charge de comparer, le 
pseudonyme et le mot de passe saisis par le client ENUM dans le foimulaire weir et 
20 les informations d'authentification contenues dans la base de donnees. En casMe 
concordance, le module d'authentification (73) notifie k I'dtape 306 le module serveur 
web (63) que I'authentification est r^ussie. Celui-ci emet k l'6tape 307, a destination 
du module script ENUM (75), vme requSte de lecture du profil ENUM. Par 
consequent, le script ENUM (75) ^met une demande d'interrogation a l'6tape 308 au 
25 module protocole DNS (62) en foumissant en argument Fadresse E.164 de I'abonn^ 
ENUM transform^ sous forme de domaine (transformation du num^ro de telephone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module protocole 
DNS (62) qui joue le rdle cbissique d'un RESOLVER interroge (k V6tape 309) aprds 
avoir vinS6 si les informations ne sont pas pr&entes dans son cache suite k une 
30 consultation pr6c6dente, k I'aide du protocole standard DNS (lequete DNS Query) 
successivement le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le 
serveur DNS de niveau 2. Pour gagner en efficacit^, les donn6es d'un DNS sont 
charg&s dans ia m^oire vive du serveur DNS (31). Si I'abonn^ ENUM est 
effectivement enregistr^ dans le DNS (31) du foumisseur de service ENUM (30), le 
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moduk protocole DNS (32) retoume h I'etape 310 les enregistrements NAPTR 
correspondaiits au module protocole DNS (62). Ce deniier les retransmet vers le 
module script ENUM (75) a I'etape 311 qui interprete les enregistrements NAPTR et 

g ^6rc un tcxte r dativem^^-^'^b^tique et c . omrrf i hen . sihle par l'alX)mi6 ENUM du . 

5 type: 

Service de priority 1 Tel: 0296053859 

Service depriorite 2 Tel: 0686166924 

Service de priority 3 Mail: b <1iipont(fl),rd.ft.com 

10 Service depriorite 4 Web: www.bertranddupont.fr, 

Ce texte est envoy^ a I'^tape 312 vers le module serveur web (63) qui t^Kcharge une 
page web munie de ces informations h I'^tape 313 vers le terminal Web (8) de 
rabomi6ENUM. 
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La page web pi^sent6e k I'abonn^ ENUM pennet via une inteifece graphique 
adapts d'opfirer des modifications de piofil ENUM courant: modification des 
priority, ajout de service, suppression de service, modification des attributs d'un 
service, etc. La demande en modification est ^e k ra^e 350 k destination du 
20 serveur web (63). Ce dernier transmet a I'^tape 351 la requSte vers le module script 
ENUM (75) qui se charge de formater la requete conformement aux entries NAPTR 
d^rites par le protocole ENUM. Le script ENUM (75) 6met alors une demande de 
raise k jour k I'etape 352 au module protocole DNS (62), Ce dernier 6met une 
commande DNS UPDATE k l'6tape 353 a destination du module protocole DNS (32) 
25 du serveur DNS (31) du founrisseur de service ENUM (30). 11 est rappele que 
I'adresse IP de ce dernier est stock^e dans la base de donn^es (70) et qu'elle est 
retrouv^e partir du num6ro E.164 de I'abonn^ ENUM. Le module protocole DNS 
(32) met k jour rinformation dans la m6moire vive du serveur (3 1) et demande la raise 
a jour de la base de donn6es (33) qui est g^n^ralement un fichier texte k plat. Le 
30 protocole DNS gere le num^ro de modification dans ce fichier de mani^ ^ ce que 
le/les serveur(s) DNS secondaire(s) puisse(nt) recharger lui/eux-mfeme(s) cette 
modification k des intervalles de temps pi^6finis. La base de donn^es (33) confirme 
la mise i jour a I'^tape 355, ce qui se traduit par une r6ponse k la requSte de demande 
de mise k jour k I'^tape 356. Le script ENUM (75) intercepte k I'^tape 357 le code 
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retour de cette r^ponse puis g^nfere k Tetape 358 le message de 
confoixiation/infimiatio de prise en compte de la modificadon avant de Fenvoyer au 
serveur web (63) qxii se charge de formater la page web de rdsultat avant de la 
tel6charger a T^tape 359 vers le terminal web (8). 

5 

La Fig. 7 illustre sch6matiquement la procedure de consultation et de 
modification manuelle d*un profil ENUM a partir d'xm Minitel. 

L'abonnd ENUM se comecte au service Minitel en utilisant la fonction PAVI 
(Point d'Accfes Videotex) du reseau de France Telecom (appel par exemple du 3615 

10 code ENUM-FT). Le terminal minitel (5) entre alors en session avec le serveur mioitel 
(57) a r^tape 400. Ce dernier active a I'etape 401 le module script ENUM (75) de la 
pr^sente invention qui gendre alors la page tfaccueil du service a F^tape 402 et qui est 
t616charg^e a I'dtape 403 sur le terminal Minitel (5) de I'abonnS ENUM . Cdtte page 
MHnitel afBche un fonnulaire d'authentification k PabonnS ENUM. Celui-ci saisit son 

15 numero ENUM E.164 puis son pseudonyme et son mot de passe. Ces informations 
sont transmises k T^tape 404 au serveur Minitel (57) qin hii meme les transmet k 
I'etape 405 au module scr5)t ENUM (75). Ce dernier redirige la requ6te k Vitape 406 
vers le module d'authentification (73). Le module d'authentification (73) interroge k 
r^tape 407 la base de donnfes locale ou distante (via une inter&ce ODBC par 

20 exemple) en operant xme recherche sur le numero ENUM R164. A T^tape 408 les 
informations d'authentification de la base de donn^ sont transmises au module 
d'authentification (73) qui les compare avec le pseudonyme et le mot de passe saisis 
dans le fonnulaire Minitel. En cas de concordance, le module d'authentification (73) 
notifie k Tetape 409 le module script ENUM (75) que Tauthentification est reussie. Le 

25 module script ENUM (75) emet alors une demande ^interrogation a Tetape 410 au 
module protocole DNS (62) en foumissant en argument Tadresse E.164 de Tabonn^ 
ENUM transformee sous forme de domaine (transformation du numero de t^tephone 
E.164 de type 33296053859 en 9.5.8.3,5.0.6.9.2.3.3.el64.arpa), Le module protocole 
DNS (62) qui joue le rdle classique d'un RESOLVER interroge (etape 411), apres 

30 avoir v6xifi6 si les informations ne sont pas pr6sentes dans son cache suite a une 
consultation pr&edente, k Taide du protocole standard DNS (requete DNS Query) 
successrvement le serveur DNS de nr/eau 0, le ser/eur dc DNS de niveau 1, puis le 
serveur DNS de niveau 2. De prdfdrence, pour gagner en eflScacite, les donnees d'un 
DNS sont chargees dans la m6moire vive du serveur DNS (3 1). Si Tabonn^ ENUM est 




22 



effectivement enregistr^ dans le serveur DNS (31) du fouraisseur de service ENXJM 
(30), le module protocole DNS (32) letoume (a F^tape 412) les enregistrements 
NAPTR correspondants. Le module de protocole DNS (62) se charge de les 
■^Mt^etfare^s4e^odul&^cript-E NT . n\/f (75) « Tpt f ipe, 413 . Oe dernier analyse et 



inteiprete les enregistrements NAPTR et g^ere un texte relativement synth6tique et 
compr^ensible par I'abonne ENUM du type: 

Service de priorite 1 Tel: 0296053859 

Service de priority 2 Tel: 06861 66924 

10 Sendee de priority 3 MaU: h dnpont(g).rd.ft.com 

Service de priorite 4 Web www.bertranddupont.fr, 

Ce texte est envoys a Fetape 414 vers le module serveur videotex (57) qui se charge 
de ta^charger k Fetape 415 vers le terminal Minitel (5) de I'abonn^ ENUM . 

15 

La page videotex pr6sent6e k Tabonn^ ENUM permet via une interfece adapt^e 
d'op6rer des modifications sur le proffl ENUM courant: modification des priorit^s, 
ajout de service, suppression de service, modification des attributs d'un service, etc. La 
requSte de mise a jour du profil ENUM est 6mise k V6tap& 450 a destination du 

20 serveur videotex (57). Ce dernier transmet a r6tape 451 la requ6te vers le module 
script ENUM (75) qui se charge de formater la requ6te conform^ment aux entrees 
NAFFR ddcrites par le protocole ENUM. Le script ENUM (75) 6met alors une 
demande de mise a jour k Fetape 452 au module protocole DNS (62). Ce dernier 6met 
une coramande DNS UPDATE a Fetape 453 a destination du module protocole DNS 

25 (32) du serveur DNS (31) du foumisseur de service ENUM (30). II est rappeM que 
I'adresse IP de ce demier est stock^e dans la base de donn^es (70) et qu'eUe est 
retrouv^e a partir du numero E.164 de I'abonne ENUM, Le module protocole DNS 
(32) met §i jour I'mformation dans la memoire vive du serveur (31) et demande la mise 
a jour de la base de donnees (33) qui est g6neralement un fichier texte k plat. Le 

30 protocole DNS gere le numero de modification dans ce fichier de manifere k ce que 
le/les serveurs DNS secondaire(s) puisse(nt) recharger Iui/eux-m&Tie(s) cette 
modification k des intervalles de temps pr^^finis. La base de donnees (33) confirme 
la mise k jour a I'dtape 455, ce qui se traduit par une r^ponse k la requSte de demande 
de mise i jour k F6tape 456. Le script ENUM (75) intercepte k F6tape 457 le code 
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retour de cette r^ponse puis g^nere h I'etape 458 le message de 
confinnation/infinnation de prise en compte de la modification avant de I'envoyer au 
serveur videotex (57) qui se charge de formater la page videotex de r&ultat avant de 
la t616charger a I'^tape 459 vers le tenninal Minitel (5). 

5 

La Fig. 8 illustre schematiquement la procedure de consultation et de 
modification manuelle d'un profil ENUM par eMail k partir d'un tenninal disposant 

dHin client eMail (8). 

L'abonne ENUM emet un eMail format^ a l'6tape 500 a destination du serveur 
10 eMail (61). La commande ENUM est par exen^le pass^e dans I'adresse eMail 
destinataire: 

el 64-33296053859-login-dupont-password-1234-requete i 
lire@gestioaenum.fi:ancetelecom.com 

15 

Le module script ENUM (75) (Kspose d'un cUent eMafl qui vient r6guU&rement 
scruter le serveur eMail (61). Lorsque le module script ENUM (75) re9oit k l'6tape 
501 un eMafl comme indiqu6 ci-dessus, il r^oqifere, soil dans I'entSte, soit dans le 
corps de FeMail, les arguments foumis puis les transmet k I'^tape 502 vers le module 

20 d'authentification (73). Le module d'authentification (73) interroge a l'6tape 503 la 
base de donn&s locale ou distante (via une interface ODBC par exemple) en 
effectuant une recherche sur le num6ro ENUM E.164. Celle-ci foumit a I'etape 504 
les informations d'authentification correspondantes au module d'authentification (73) 
qm les compare au pseudonyme (loginjd) et au mot de passe (password) foumis par 

25 le cUent ENUM dans I'eMafl. En cas de concordance, le module d'authentification 
(73) en avertit le module script ENUM (75) h I'etape 505. Par consequent, le script 
ENUM (75) 6met une demande ^interrogation k l'6tape 506 au module de gestion de 
protocole DNS (62) en foumissant en argument I'adresse E.164 de I'abonn^ ENUM 
transform^e en nom de domaine (transformation du num^ro de t616phone E.164 de 

30 type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de 
protocole DNS (62) qui joue le rdle clasaque dHan RESOLVER interroge (6tape 507), 
si toutefois les informations nc son! pas d6}k prdsentes dans son cache suite k une 
consultation pr6c6dente, selon le protocole standard DNS (requ6te DNS Query) 
successivanent le serveur DNS de niveau 0, le serveur de DNS de niveau 1, puis le 
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serveur DNS de niveau 2 par la pfle de protocole DNS (32). De preference, pour 
gagner en efficacite, les donntes d'un DNS sont chargtes dans la m^moire vive du 
serveur DNS (31). Si rabomi6 ENUM est effectivement enregistr6 dans le DNS (31) 
du foumis seiff-de-SCTvie e ENUM (30) aIors 4e-gK)du]fi-de-^stio n de pmtoool p . DN S 
(32) retoume ^ r^ape 508 les enregistrements NAPTR correspondants. Le module de 
gestion de protocole DNS (62) se charge de les retransmettre vers le module script 
ENUM (75) h I'etape 509. Ce dernier analyse et interpr^e les enregistrements 
NAPTR et g,€abre un texte relativement syntMtique et comprehensible par I'abonn^ 
ENUM du type: 

Service de priority 1 Tel: 0296053859 

Service de priority 2 Tel: 06861 66924 

Service de priorite 3 Mail: b.dupont@.rd.ft.com 

Service de priority 4 Web T^'ww.bertranddupont.fr. 

Ce texte est expedie (etape 510) sous forme d'eMail par le lo^iel client eMail 
iat6g^ dans le module script ENUM vers le module serveur eMail (61) qui se diarge 
de I'envoyer vers Tabonne ENUM. 

20 L'abonn6 ENUM qui souhaite modifier son Proffl ENUM envoie un eMaU 

formate k V€tape 550 a destination du serveur eMail (61). La commande ENUM est 
par exemple pass^e dans I'adresse eMail destinataire, par exen^Ie: 
el64-33296053859-logm-dupont-password-1234-requete-ecaTre-Pl-tel-0296053859- 

P2-tel-0686166924-P3-fex-0296050242@gestion.enum.francetelecom.com 

25 

Le client eMail du module script ENUM scrute le serveur eMail (61). Lorsque le 
module script ENUM re9oit (en 551) un eMail comme indique ci-dessus, fl r^cupere, 
soit dans I'entete, soit dans le corps de FeMail, les arguments foumis puis les transmet 
a I'etape 552 vers le module d'authentification (73). Le module d'authentification (73) 
30 inteiToge k I'etape 553 la base de donndes locale ou distante (via une interface ODBC 
par exemple) en operant une recherche sur le numero ENUM E.164. CeUe-ci foumit k 
I'etape 554 les informations d'authentification correqaondantes el le module 
d'authentification (73) les compare au pseudonyme et au mot de passe foumis dans 
I'eMail. En cas de concordance, le module d'authentification (73) en avertit le module 
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script ENUM (75) ^ I'^tape 555. Ce dernier formate la requSte conform^ment aux 
entries NAPTR decrites par le protocole ENUM. Le script ENUM (75) transmet alors 
une demande de mise k jour a I'^tape 556 au module de gestion de protocole DNS 
(62) qui emet une commande DNS UPDATE a I'etape 557 a destination du module 

5 protocole DNS (32) du serveur DNS (31) du foumisseur de service ENUM (30). II est 
rappete que I'adresse IP de ce dernier est stockee dans la base de donnees (70) et 
qu'elle est retrouv^e a partir du numero E.164 de rabonn6 ENUM. Le module 
protocole DNS (32) met ^ jotrr Tinformation dans la m^moire vive du serveur (31) et 
demande la mise a jour de la base de donnees (33) qui est g^n^ralemeot un fichier 

10 texte a plat. Le protocole DNS g^re le numero de modification dans ce fichier de 
maniere k ce que le/les serveur(s) DNS secondaire(s) puisse(nt) recharger hn/eux- 
m6me(s) cette modification a des intervalles de temps pr6d6finis. La base de doni^s/ 
(33) confinne la mise k jour k I'^tape 559, ce qui se traduit par une rSponse k la 
requSte de demande de nrise k jour k I'fitape 560. Le module script ENUM (75) 

15 intercepte k V&ape 561 le code retour de cette rdponse puis g6nhie le message de 
confirmationMcmation de prise en compte de la modification. Cc message est 
exp^6 (a raape 562) sous forme d*eMail par le logiciel client int6gr6 dans le 
module script ENUM au serveur eMail (61). Ce dernier envoie a I'^tape 563 I'eMail 
en question a Fabonn^ ENUM qui peut le consult« sur son tamninal (8) . 

20 

La Fig. 9 illustre sch6matiquement k procedure de consultation et de 
modification manuelle d'un profii ENUM par lUU (Information d'Usager k Usager) a 
partir d'un terminal RNIS (2). 

L'abonne ENUM tot k I'etape 600 depuis son terminal RNIS (2) un appel 

25 tel6phonique contenant I'eMment d'information lUU vers I'interfece RNIS (51). II feut 
rappeler que le champ lUU est actuellement limite k une taille de 32 caractdres. La 
commande ENUM qui est 'ms6t6e dans le champ lUU ne pourra done agir que sur un 
service ENUM k la fois. Par exemple: GetPl-33296053859*dupont#123456: cette 
requSte permet de r&updrer les attributs du service ENUM de priority 1 - 

30 L'automate d'appel (52) transmet k I'dtape 601 le message de dCTiande 

d'^tablissement d'appel au module lUU (53) qui va extraire la commande lUU. 
L'automate d'appel (52) dmet k T^tape 652 le message Alerte k destination de I'abomi^ 
ENUM de xxmatro k s'autoriser un mintnmim de tenq>s (temporisation du protocole 
RNIS avant d'envoyer un message de d6conne3don). Le module lUU (53) transmet la 
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coimnande ENUM k I'etape 603 vers le module script ENUM (75). Ce demier 
rScup^sre les arguments ENUM foumis puis les transraet a I'etape 604 vers le module 
d'authetitification (73). Le module d'authentification (73) interroge a I'etape 605 la 

,.se^e-doim^es4ocale- ou dist a nfc (via une l u terfece ODBC par exei n ple) en operant ., 
une recherche sur le num6ro ENUM E.164. Celle-ci foumit a I'etape 606 les 
infonnadons d'authentification correspondantes au module d'authentification (73) qui 
les compare avec le pseudonyme et le mot de passe foumis par le cUent ENUM ckns 
riUU. En cas de concordance, le module d'authentification (73) en avertit le module 
script ENUM (75) k I'etape 607. Par suite, le module script ENUM (75) ^met une 
10 demande d'interrogation a I'^ape 608 au module de gestion de protooole DNS (62) en 
foumissant en argument I'adresse E.164 de I'aborai^ ENUM transform^ sous forme 
de domaine (transformation du numero de t6l6phone E.164 de type 33296053859 en 
9.5.8.3 .5.0.6.9.2.3.3.el64.aipa). Le module de gestion de protooole DNS (62) quijoue 
le r61e classique d'un RESOLVER peut interroger (k T^tape 609), ^s avoir v6rifi6 a 
1 5 les informations ne sont pas d^i dans son cache suite k une consultation pr6c6dente, a 
I'aide du protocole standard DNS (requdte DNS Query) le DNS niveau 0 puis le DNS 
niveau 1, puis le DNS mveau 2 via son module de protocole DNS (32). De 
prdlKtence, pour gagner en efficacit6, les donaSes d'un serveur DNS sont chargees 
dans la m&noire vive du serveur (31). Si I'abonne ENUM est effectivement enregistrd 
20 dans le DNS (31) du foumisseur de service ENUM (30), la pile de protocole DNS (32) 
retoume k I'etape 610 les enregistrements NAPTR correspondants au module de 
gestion protocole DNS (62) qui se charge de les retransmettre vers le module script 
ENUM (75) a I'etape 611. Ce demier analyse et interprete les enregistrements 
NAPTR et en fonction du service demand6 dans la commande lUU genere un texte 
25 relativement synth6tique et compr6hensible par I'ahonn^ ENUM du type: 

Service PI: Tel:0296053859 

Ce texte est envoye k I'etape 612 vers le module lUU (53) qui se charge de 
30 formater un message de d^connexion avant de lenvoyer k I'etape 613 au module 
automate d'appel (52). Ce demier g^ndre le message de d6connexion RNIS qui 
conticHt Peiemenl d'informaiion lUU et qui est done transmis k I'^ape 614 via le 
r^seau RNIS au terminal (2) de l'abonn€ ENUM. Ce demier peut visualiser ITUU sur 
I'afEicheur de son terminal RNIS (2). 
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L'abotme ENUM qui souhaite modifier son profil ENUM emet a Tetape 650 
depuis son ternrinal RNIS (2) un appel t^lephonique contenant Telement d'information 
lUU vers I'interface RNIS (51). Par exemple: DelP3-33296053859*dupont#I 23456: 
cette requete permet de supprimer le service ENUM de priorite 3. 
5 L'automate d'appel (52) transmet a Tetape 651 un message de demande 

d'etablissement d'appel an module lUU (53) qui extrait la commande lUU. L'automate 
d'appel (52) emet a Tetape 652 le message Aierte a destination de I'aborai^ ENUM de 
manidre a s'autoriser xm minimum de temps (temporisation du protocole RNIS avant 
d'envoyer un message de deconnexion). Le module lUU (53) transmet la commande 

10 ENUM a r6tape 653 vers le module script ENUM (75). Ce dernier r&upere les 
arguments foumis puis les transmet h Tetape 654 vers le module d'authentification 
(73)* Le module d'authentification (73) interroge a T^tape 655 la base de donn6es 
locale ou distante (via une interfece ODBC par exen^le) en operant une recherche sur 
le num6ro ENUM E.164. Celle-ci foumit k Tetape 656 les informations 

15 d'authentification correspondantes au module d'authentification (73) qui les compare 
au pseudonyme et au mot de passe foumis par le client ENUM dans TIUU. En cas de 
concordance, le module d'autiientification (73) en avertit le module script ENUM (75) 
a Tetape 657* Etant donn6 que la modification ne porte pas sur Tensemble du profil, le 
script ENUM (75) 6m&t d'abord une demande d'interrogation (a Tetape 658) au 

20 module de gestion de protocole DNS (62) en foumissant en argument Tadresse E.164 
de Tabonnd ENUM transformee sous forme de domaine (transformation du numero de 
telephone E.164 de type 33296053859 en 9.5.83.5.0.6*9,2.33-el64.arpa). Le module 
de gestion de protocole DNS (62), qui joue le r61e de RESOLVER, peut interroger (a 
Tetape 659), apxbs avoir verifie si les informations ne sont pas dej^ dans son cache 

25 suite a une consultation precedente, a I'aide du protocole standard DNS (requete DNS 
Query) le DNS niveau 0, le DNS niveau 1 puis le DNS niveau 2 via son module de 
protocole DNS (32)- Pour gagner en efl&cacite, les donnas d*un DNS sont chargees 
dans la memoire vive du serveur (31). Si I'abonnS ENUM est e£fectivement enregistrd 
dans le DNS (31) du fbumisseur de service ENUM (30), le module protocole DNS 

30 (32) retoume a Tetape 660 les enregistrements NAPTR correspondants au module de 
gestion de protocole DNS (62). Ce dernier se charge de les retransmettre vers le 

c^;-rs4- TTXTf TAyf 1^7^ a T A p/»f|n-f PT\TTT1V/f /''7S^ ^^vvi^ ainvc iin«» 

demande de mise a jour en tenant compte de la modification demandSe dans le champ 
lUU a Tetape 662 au module protocole DNS (62). Ce dernier 6met une commande 
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DNS UPDATE h I'^ape 663 k destination du module protocole DNS (32) du serveur 
DNS (31) du foumisseur de service ENUM (30). II est rappele que I'adresse IP de ce 
dernier est stock^e dans la base de donnees (70) et qu'elle est retrouvee a partir du 
numdro E164 v ^ h nnnA FNTTM . T ,e m odule protocole DNS (32) met k jour 



5 I'information dans la memoire vive du serveur (31) et demande la nrise a jour de la 
base de donndes (33) qui est g6neralement un fichier texte a plat. Le protocole DNS 
gere le num6ro de modification dans ce fichier de maniere a ce que le/les serveurs 
DNS secondaire(s) puisse(nt) recharger lui/eux-meme(s) cette modification k des 
intervalles de temps pred^finis. La base de donnees (33) confiime la mise 4 jour a 

10 r^tape 665, ce qui se traduit par une r^ponse a la requSte de demande de nnse ^ jour k 
Vct^c 666- Le script ENUM (75) intercepte a I'^tape 667 le code retour de cette 
r6ponse puis g^ndre a I'dtape 668 le message de confirmationTinfiiTOation de prise en 
compte de la modiffcation. Ce message est envoy6 k I'^tape 668 le module lUU 
(53) qui se charge de formater un message de d^connexion avant de I'envoyer k I'^tape 

15 669 au module automate d'appel (52). Ce dernier g6ndre k Pftape 670 le message de 
d6connexion RNIS qui contirait Mdment d'information lUU et qui est done transmis 
via le r6seau RNIS vers le terminal (2) de rabonn^ ENUM. Ce dernier peut visualiser 
riUU sur raf&cheur de son terminal RNIS (2). 

20 La Fig. 10 illustre sch^tiquement la procedure d'accfes au service de 

consultation et de modification automatique d'un profil ENUM a partir d'une session 
vfeh. La tache consistant a modifier manuellement un profil ENUM peut vite devenir 
deUcate et r6p6titive. Un automate (dit automate de configuration) est alors utilise 
pour efiectuer une modification automatique du profil ENUM en fonction du temps 

25 et/ou d'autres parametres. Parmi ces autres paramdtres, la locaUsation de Pabonne 
peut 6tre retenue si elle est connue du systeme (50). 

L'abonn^ ENUM demande k Petape 700 le t61tehargement de la page web 
d'accueil du service de gestion du profil ENUM. CeUe-ci est retourafe k I'^tape 701 
par le serveur web (63) de la pr&ente invention. Cette page web affiche un formulaire 

30 d'authentification k I'abonnd ENUM. Celui-ci saisit son numero ENUM E.164 puis 
son login et mot de passe. Ces infommtions sont transmises k I'etape 702 au serveur 
web (63) qui iui wBms les transmet (k Petape 703) au module d'authentification (73). 
Le module d'authentification (73) interroge (k P^ape 704) la base de donntes locale 
ou distante (70) (via une interfece ODBC par exenq>le) en operant une recherche sur 




le nura6ro ENUM E.164. Cette-ci foumit a I'^tape 705 les informations 
d*authentification coirespondantes au module d'authentification (73) qui les compare 
avec le pseudonyme et le mot de passe saisis par le cUent ENUM dans le formulaire 
web. En cas de concordance, le module d'authentification (73) notifie h I'etape 706 le 
module serveur (63) que I'authentification est r6ussie. Celui-ci 6met k I'^tape 707 
k destination du module scrqjt ENUM (75) une requSte en lecture de la configuration 
automatique pour ce profil ENUM. Le module scr5)t ENUM (75) interroge k l'6tape 
708 la base de demises (70) en foumissant en arguments le num^ro E.164 de I'abonn^ 
ENUM. La base de donn^es (70) retoume a I'dtape 709 le programme de gestion 
automatique du profil au module scr9>t ENUM(75). Ce dcmier met en forme les 
informations, par exen^le: 

Lundi au Vendredi: de 08:30 k 19:00 
PI Tel 0296053859 
P2 Tel 0686166924 

P3 eMail bertrand.dupont@rd-fiancetelecom.com 
P4 fex 0296050242 

Lundi au Vendredi: de 19:00 k 08:30 
PI Tel 0296916404 

P2 eMail bartrand.dupont@rd.firancetelecom.com 

Samedi et Dimanche: de 00:00 k 23:59 

PI Tel 0296916404 

P2 Tel 0686166924 

P3 eMail bdupont(g>wanadoo.fi- 

Le module script ENUM (75) transmet les informations format6es k T^tape 710 
au serveur web (63) qui se charge de t616charger la page web contenant les 
informations en clair du programme de configuration du profil ENUM sur le terminal 
web (8) de rabonn6 ENUM. 

Cette page web permet la modification da programme de configuration 
automatique du profil ENUM: modification des horaires, gestion des jours Kri^s, 
ajout-suppression de service, modifications des attributs des services, etc. L'abonn6 
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ENUM valide la modification du programme h I'^tape 750. Le serveur Web (63) 
transmet ces infoimations t I'dtape 751 vers le module script ENUM (75). Ce dernier 
extrait les informations, les met en fornie selon un format defini avant de les ecrire 

^^a^ase-de-deHa6es47Q>,-4ai^apeJ752. Xe1 1 e-d prend en compte I'ei ge gistrement . . 
du programme et le confirme k I'etape 753 au module script ENUM (75). Ce dernier 
notifie au serveur web (63) i I'etape 754 la prise en compte de la modification de 
I'automate de configuration du profil ENUM. Le serveur telecharge k I'aape 755 la 
page web de confirmation de la modification sur le terminal web (8) de I'abonn^ 
ENUM. 

La Fig. 11 iHustre la procedure de mise a jour automatique par Fautomate de 
configuration des profils ENUM ainsi que la procedure optionnefle de notification de 
changement de profil vers I'abonn^ ENUM. 

L'automate de configuration (74) scmte r^guli&rement a I'^tape 800 la base de 
donn^es (70) pour verifier s'il y a une modification programm^e k r6aliser (en fonction 
du jour et de ITieure courants). Si une modification est programme alors les 
paiametres de configuration sont rctoumes a F^pe 801. L'automate de configuration 
(74) €met une demande ^interrogation k l'6tape 802 au module de gestion de 
protocole DNS (62) en fi>umissant en argument Tadresse E.164 de I'abonnd ENUM 
dont le profil est h modifier, transform^ sous forme de nom de domaine 
(transformation du num^ro de t^l^phone E.164 de type 33296053859 en 
9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion de protocole DNS (62) qui 
joue le rdle d'un RESOLVER peut interroger (4 Tetape 803), si toutefois les 
informations ne sont pas d6ja dans son cache suite k une consultation prfe6dente, a 
I'aide du protocole standard DNS (requ6te DNS Query), le serveur DNS niveau 0, le 
serveur DNS niveau 1, puis le serveur DNS niveau 2 via son module de protocole 
DNS (32). De preference, pour gagner en efficacite, les donn&s d'un DNS sont 
charg6es dans la m6moire vive du serveur DNS (31). Si I'abonn^ ENUM est 
eflectivement enregistr^ dans le DNS (31) du foumisseur de service ENUM (30) alors 
le module protocole DNS (32) retoume k I'dtape 804 les enregistrements NAPTR 
correspondants au module protocole DNS (62). Ce dernier les retransmet vers 
l'automate de configuration (74) qui consulte alors (6t^e 806) la base de donn&s 
(70) aSn de r^cuperer les modifications k op6rer sur le profil ENUM. La base de 
donndes retoume (6tape 807) le profil k appKquer au module automate de 




configuration (74). Si une modification est effectivement n&essaire (le profil a pu 
entre ten^>s 6tre modifi6 manuelkanent), rautomate de configuration determine les 
modifications k apportra- aux enregistrements NAPTR et 6met une demande de mise k 
jour h r6tape 808 au module de gestion de protocole DNS (62). Ce dernier 6met une 
commande DNS UPDATE a V6tape 809 a destination du module protocole DNS (32) 
du serveur DNS (31) du foumisseur de service ENUM (30). II est rappel6 que 
I'adresse IP de ce dernier est stock6e dans la base de donn^es (70) et qu'elle est 
retrouv^e k partir du numero E.164 de I'abonn^ ENUM. Le module protocole DNS 
(32) met a jour I'infbramtion dans la m^moire vive du serveur (3 1) et demande la mise 
a jour de la base de donnees (33) qui est g6n6ralement un fitdiier texte k plat. Le 
protocole DNS g^re le num6ro de modification dans ce fichier de mani^ i ce que 
le/les serveurs DNS secondaice(s) puisse(nt) recharger hxi/eux -m^e(s) cette 
modification k des intervalles de temps pred^finis. La base de donates (33) confirme 
la mise k jour k 1' 6tape 81 1, ce qui se traduit par une r^ponse k k requSte de demande 
de mise a jour k I'etape 812. Le module automate de configuration (74) intercepte k 
V€tap& 813 le code retour de cette r^ponse puis g€abre k Vetsipe 814 une demande 
d'^criturc dans la base de donn^ (70) pour alimenter le journal des modifications. La 
base de donnfes (70) confirme V6cdtate de Kv^nemetit de modification automatique 

du profil a I'^tape 815. 

Si le sennce de mise k jour automatique a €16 configure pour notifier les 
modifications autoroatiques de profil ENUM, I'automate de configuration notifie la 
mise li jour selon xm ou phisieurs des modes suivants : 

o dans le cas ou la notification est en mode vocal, I'automate de configuration 
(74) notifie I'automate d'appel (52) a Tetape 820, ce qui se traduit par un 
appel t^lephonique vers un t616phone fixe RTC (4), ou RMS (2), ou IP (7) ou 
vers un t^ldphone mobfle (6). Les informations et adresses de notification 
sont stock^es dans la base de donnfes (70). L'abonn6 ENUM r6pond k cet 
appel tdlephonique k I'^tape 822 ou I'appel est aiguill6 vers sa messagerie 
vocale. Le module de synthase vocale (55) ou le module de diffusion de 
fichiers vocaux (56) diffuse k I'dtape 823 la notification de la modification de 
profil ENUM, par exeraple: "bonjour, votre profil ENUM 33296053859 a 6te 
mis k jour aujourdliui k 19:00 comme suit: service t616phonique vers 
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0296053859 puis service t61ephonique vers 0686166924 puis service eMail 
vers bertrand.dupont@wanadoo.fr ": 

o — dms^c cas ou l a notifi e^efr-es^^flra ode - SMS - y autonaate-4e-€OBfi§OT^ 

5 (74) avertit le module SMS (58) a I'etape 830 en foumissant le texte du SMS 

par example du type: "Modification de votre proffl ENUM 33296053859 le 
21/03/2002 a 09:00: tel:0296053859, t61: 0686 166924,fax: 0296050242". Le 
module SMS (58) transmet a F^tape 840 ce message SMS a destination du 
temiinal t^lephonique mobile ou fixe, tel que configure dans la base de 
10 donnees (70) ; 

o dans le cas ou la notification est en mode eMail, Tautomate de configuration 
(74) notifie la mise k jour au serveur eMail (61) (etape 850) a Taide d'un 
eMail contenant un texte du type: "Modification de votre profil ENUM 
15 33296053859 le 21/03/2002 a 09:00: t^l:0296053859, tel:06861 66924, 

fex:0296050242". A cette fin, I'autonmte de configuration dispose d'un client 
eMaiL Le serveur eMail (61) transmet ensuite h T^tape 860 FeMail en 
question k Tadresse eMail stock^e dans la base de donnees (70) ; 

20 o dans le cas ou la notification est en mode fex, Tautomate de configuration 

(74) notifie au module fex (59) k T^tape 870 en foumissant le texte du fex qui 
pourrait 6tre de type: "Modification de votre profil ENUM 33296053859 le 
21/03/2002 a 09:00: tel:0296053859, t61:0686166924,fax:0296050242". Le 
module fax (59) transmet a Tetape 880 ce fax a destination du terminal fax 

25 (9) configure dans la base de donnees (70). 

La Fig. 12 iUustre un exemple de procedure de consultation de profil ENUM 
lorsque ce dernier est stocks dans un annuaire LDAP. L' exemple donn^ en Fig. 12 
illustre une consultation via un ordinateur individuel mais il est clair que la 
30 consultation peut etre r^alisfe au moyen des autres types de terminaux pr6cedemment 
envisages. Ce type de service pourrait notamment etre propos6 par des entreprises qui 
souhaiteraient oflSrir i^acces a im service ENUM a toute ou partie de leurs employes, 

L'abonn6 ENUM demande k V6tape 900 le t61&;hargement de la page web 
d'accueil du service de gestion du profil ENUM. Celle-ci est retoum^e k T^tape 901 




par le serveur web (63) du systdme (50). Cette page web affiche un fonimlaire 
d'authentification k rabonn^ ENUM. Celutci saisit son num6ro ENUM E.164 puis 
son pseudonyme et son mot de passe. Ces mformations sont transmises a I'^tape 902 
au serveur web (63) qui hii mSme les transmet (6tape 903) au module 
d'authentification (73). Le module d'authentification (73) interroge (etape 904) la base 
de donn^es locale ou distante (via une interfece ODBC par exemple) en operant une 
recherche sur le num^ro ENUM E.164. CeUe-ci foumit a I'etape 905 les infonnations 
d'authentification correspondantes au module d'authentification (73) qui se charge de 
les comparer avec le pseudonyme et mot de passe saisis par le client ENUM. En cas 
de concordance, le module d'authentification (73) notifie h I'dtape 906 le module 
serveur web (63) que I'authentification est r6ussie. Celui-ci 6met k I'^tape 907 k 
destination du module script ENUM (75) une requite de lecture du profil ENUM. .Le 
script ENUM (75) emet une demande d'interrogation a I'^tape 908 au module de 
gestion de protocole DNS (62) en foumissant en argumCTt I'adresse E.164 de I'aboim^ 
ENUM transfoim6e sous forme de domaine (transfonnation du num^ro de t^ldphone 
E.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.el64.arpa). Le module de gestion 
de protocole DNS (62) qui joue le i61e d'un RESOLVER intewoge (^tape 909), si les 
informations ne sont pas d6^ dans son cache suite k une consultation pr6c6dente, - ^ 
I'aide du protocole standard DNS (requ6te DNS Query), le serveur DNS de niveau 0, 
le serveur DNS de niveau 1, puis le serveur DNS de niveau 2 via son module de 
protocole DNS (32). De pr^JKrence, pour gagner en efficacite, les donnees d'un DNS 
sont chargees dans la m^moire vive du serveur (31). Si I'abomi^ ENUM est 
efifectivement enregistr^ dans le serveur DNS (31) du foumisseur de service ENUM 
(30), le module de gestion de protocole DNS (32) retoume k I'etape 910 le/Ies 
emegistrement(s) NAPTR correspondant(s) . Le module de gestion de protocole DNS 
(62) se charge de les retransmettre vers le module script ENUM (75) k I'etape 911. Ce 
deraier analyse et interprete le/les enregistrement(s) NAPTR, par exenq)le: 

$ORIGIN9.5.8.3.5.0.6.9.2.3.3.el64.arpa. 

IN NAPTR 100 10 "u" 

"ldap+E2U""!^+33296053859$!ld^://ld^.foumisseurA.fi:/cn=33296053859•" 

Le script ENUM d6tecte qu'fl s'agit d'un service LDAP. Par consequent, le 
module scnpt ENUM (75) 6met k l'6tape 912 k destination du module de gestion 
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protocole LDAP (64) une requgte LDAP de demande de connexion vers le serveur 
LDAP i^f&enc6 par ITJRI "ldap://ldap.foumisseurA.fr". Ce dernier emet a I'etape 913 
une requete "Bind" k destination du module protocole LDAP (35) du serveur annuaire 

I^A]^•^4>-dH^^g|asseur-EmJ^ ^ (30) T.r modu l e protocole LDAP(35) accepte la 

5 connexion a Pet^e 914. Le module de gestion de protocole LDAP (64) emet alors k 
r^tape 915 a destination du module protocole LDAP (35) la requgte LDAP "Search" 
en foumissant le numero E.164 de I'abonnd ENUM en argument. Le module protocole 
LDAP (35) interroge la base de donnees LDAP (36) a Petape 916 puis retoume (a 
I'etape 917) I'ensemble des informations concemant I'abonn^ ENUM au module 
10 protocole LDAP (35) qui lui-raeme les retoume (etape 918) au module de gestion de 
protocole LDAP (64). Ce dernier retoume les informations k Vitape 919 au script 
ENUM (75) qui se charge de les mettre sous une forme comprehensible pour Tabonn^ 
ENUM avant de les transmettre (k I'etape 922) vers le serveur web (63). Le serveur 
telecharge ensuite la page web gener^e dynamiquement k I'etape 923 sur le terminal 
15 web (8) de I'abonn^ ENUM. En paraB^le, le module de gestion de protocole LDAP 
(64) envoie k I'etape 920 une demande de d6connexion au serveur LDAP (34) via une 
requite "Unbind". Le module de protocole LDAP (35) confiime la d6conne3don k 
l'6t^e921. 

20 La Fig. 13 d^crit la procedure de modification manueUe de profil ENUM 

lorsque ce dernier est stocke dans un annuaire LDAP. Lk encore, une modification de 
profil ENUM par un terminal autre qu'un PC peut bien entendu 6tre envisagde. 

L'abonn6 ENUM ayant pr^cedemment consulte le contenu de son profil ENUM 
au moyen de la procedure decrite ci-dessus, peut decider de le modifier. Pour ce faire, 

25 il modifie localement dans la page web affich6e sur son terminal web (8) les attributs 
de ses services ENUM, les priorites, ajoute des services ou en supprime. II valide ses 
modifications de profil k I'etape 1000 et les informations sont foumies au serveur web 
(63). Ce dernier transmet I'ensemble de ces informations k l'6tape 1001 au module 
script ENUM (75). Ce demia: 6met une demande d'inteirogation k I'ftape 1002 au 

30 module protocole DNS (62) en foumissant en argument I'adresse E.164 de rabonn6 
ENUM transformee sous forme de domaine (transformation du nurn&o de telephone 
£.164 de type 33296053859 en 9.5.8.3.5.0.6.9.2.3.3.eI64.arpa). Le module de gestion 
de protocole DNS (62) qui joue le role d'un RESOLVER peut interroger. si les 
informations ne sont pas d6jli dans son cache suite a une consultation pr^c^dente (k 
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I'^tape 1003) avec le protocole standard DNS (requSte DNS Query) le DNS niveau 0, 
puis le DNS niveau 1, avant d'interroger le DNS niveau 2 via son module de protocole 
DNS (32). Pour gagner en eflBcacit6, les donnees d'un DNS sont charg^es dans la 
memoire vrve du serveur DNS (31). Si I'abonne ENUM est eflfectivement enregistr6 
5 dans le DNS (31) du foumisseur de service ENUM (30) le module protocole DNS 
(32) retoume k I'etape 1004 le/les enregistrements NAPTR correspondant(s). Le 
module de gestion de protocole DNS (62) les retransmet alors vers le module script 
ENUM (75) a I'etape 1005. Ce dernier analyse et interpr^te le/les enregistrement(s) 
NAPTR, par Qxeiaple : 

10 

$ORIGIN9.5.8.3.5.0.6.9.2.3.3.el64.aipa. 

INNAPTRlOOlO 'V 

"ldap+E2U""!^+33296053859$!ldap://ldap.foumisseu^A-fr/c^=3329605385^!•• 

15 Le module sa^ ENUM (75) d^ecte qu'il s'agit d'un service LDAP. Le 

module script ENUM (75) 6mst alors (etape 1006) h. destination du module protocole 
LDAP (64) une requite LDAP de demande de comiBnon au serveur LDAP r6^renc6 
par lOJRI "Idapr/Zld^.foumisseurA.fr''. Ce demia* 6met h Vitapet 1007 une requite 
"Bind" k destination du module protocole LDAP (35) du serveur annuaire LDAP (34) 

20 du foumisseur ENUM A (30). Le module protocole LDAP(35) accepte la connexion ^ 
r^tape 1008. Le module protocole LDAP(64) emet alors k I'etape 1009 a destination 
du module protocole LDAP (35) une requite LDAP "Search" en foumissant le 
num6ro E.164 de I'abonne ENUM en argument. Le modvde protocole LDAP (35) 
interroge la base de donnees LDAP (36) k I'etape 1010 puis retoume k I'etape 1011 

25 I'ensemble des informations concemant rabonnd ENUM au module de gestion de 
protocole LDAP (35). Ce dernier les retoume k r6tape 1012 vers le module de gestion 
de protocole LDAP (64) qui lui-m6nate les retoume (etape 1013) au module de script 
ENUM (75), Cehii-ci les compare avec les informations foundes via le web par 
Fabonne ENUM et determine reparation k eflfectuar au format LDAP et transmet une 

30 demande de modification k P^tape 1014 k destination du module de gestion de 
protocole LDAP (64). Ce dernier envoie une requdte LDAP "Modify" k Vetape 1015 k 
destination du module protocole LDAP (35) qui lui-mSme 6met k T^tape 1016 une 
demande d'dcriture dans la base de donnees (36). Celle-ci accepte la mise a jour et la 
confirme (6tape 1017) au module protocole LDAP (35). Ce dernier transmet (6tape 



■ — ■ f - - 

36 



1018) la confirmation/infiniiation dc raise k jour au module de geslion de protocole 
LDAP (64) qui la retoume (etape 1019) au module script ENUM (75). Celul-ci genere 
alors la page web de confinnation de modification avant de la transmettre au serveur 
_^;TOb-(63)^e serveur t^.lfeharge ce tte p agejsta pe 1023) au terminal web (8) de 
5 rabonne ENUM. En parallele, le module protocole LDAP (64) envoie (etape 1020) 
une demande de deconnexion au serveur LDAP (34) via une requete "Unbind". Le 
module de protocole LDAP (35) confiime la deconnexion k I'etape 1021. 

Bien que la procedure de mise a jour d'annuaire LDAP ait 616 illustrfc pour une 
10 procedure « manuelle », U va de soi qu'une mise k jour automatique de I'ammaire 
LDAP au moyen de I'automate de configuration (74) peut 6galement 6tre raivisagee. 

Bien que I'invention ait 6t6 essentieDement d&rite dans le cadre de I'appfication 
« ENUM » et de la mise k jour d*un piofil ENUM , fl est clair pour 1' homme du metier 
15 qu'eUe peut s'^endre h la mise k jour d'un ou phisieurs enregistrement(s) de 
ressource(s) (RR) dans un serveur DNS (ou LDAP), tels que d^finis au paragraphe 
3.2.2 du document RFC 1 035 pr6cit6 et repris dans la table ci-aprSs : 



Type de RR 


Valeur 


Signification 


A 


I 


Addresse IP d'une machine 


NS 


2 


Nom de serveur g6[6 par une autorite admirastrative 


MD 


3 


Serveur Mail de destination 


MF 


4 


Serveur Mul de r^utage 


CNAME 


5 


Nom canonique pour un alias 


SOA 


6 


Marque le d^but d'une zone d'autoritd 


MB 


7 


Nom de domaine d'une boite eMml 


MG 


8 


Membre de groupe de mail 


MR 


9 


Nom de domaine de renommage d'xm mail 


NULL 


10 


Resource record NULL 


WKS 


11 


Description de service bien connu 


PTR 


12 


Pointeur sur un nom de domaine 
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HENFO 


13 


Information sur une machine infonnatique 


MINFO 


14 


Information sur une boite mail 


MX 


15 


Echange de mail 


TXT 


16 


C3iaines de caracteres 



Pour un enregistrement de ressource donne, la mise a joxir pourra porter sur un 
ou plusieurs champs de cet enregistrement, tels que d6fini$ dans le document RFC 
1035 prdcit6. 

5 II feut noter que si la raise jour d*enregistrement(s) de ressources autre(s) que 

NAPTR est envisagfe, de nouveaux modules siniilaires au module « Script ENUM » 
(75) et « automate de configuration ENUM » (74) doivent 6tre ajoutfe pour trailer 
chacun de ces enregistrements. > 
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REVENDICATIONS 



4)-^yst6me^e-^eflsidt^oH^tA)u de mis p « jm i r d^m enregistrement stocke dans 



5 une premise base de doimees (33, 36), ledit enregistrement comprenant un ou une 
pluraUte d'enrcgfatrements de ressources (RR), ladite premiere base de donn6es etant 
hebergee par un serveur de noms de domaine, dit serveur DNS, ou un serveur 
d'annuaire, dit serveur LDAP, pouvant etre acced6 par indirection a partir d'un 
serveur DNS, caract6ris6 en ce qu'il comprend : 

10 - des moyens de communication (1150, 53-59, 61,63) permettant audit systfeme 

de recevoir d'un terminal de telecommunication une demande de consultation et/ou de 
modification dudit enregistrement ou une programmation d'une teUe demande ; 

- des moyens de controle (1175, 74, 75) adapt^s k determiner h partir de ladite 
demande de consultation et/ou de modification transmise au dit systfeme ou 

15 pr^alablement programmee dans ledit syst^, un nom de domaine et une op&ation a 
efifectuer sur ledit enregistrement ; 

- des moyens de gestion de protocole (1 162, 62, 64) adapts k rechercher a partir 
dudit nom de domaine, I'adresse IP dudit serveur hebergeant ladite premi^ base de 
donnfes et, en fonction de ladite operation, ^itransmettie au dit serveur une requete de 

20 lecture ou de mise jour dudit enregistrement. 

2) Systdme selon la revendication 1, caract6rise en ce qu'il comprend des 
moyens d'authentification (1173, 73) adaptes a authentifier au niveau appUcatif 
r^metteur de ladite demande a partir d' informations d'authentification stock^es dans 

25 une seconde base de donn^es (1 170,70) locale ou distante. 

3) Syst^me selon la revendication 2, caract6rise en ce que, I'&netteur de ladite 
demande ayant ^e authentifi6, lesdits moyens de gestion de protocole sont ad^tes k 
transmettre une requete en consultation selon le protocole DNS (DNS Query) audit 

30 serveur DNS, la requSte ayant pour argument ledit nom de domaine, et k recevoir une 
premiere r6ponse dudit serveur. 

4) Systfeme selon la revendication 3, caract6ris6 en ce que la prbmifere base de 
donnfes 6tant h6berg6e par ledit serveur DNS, les moyens de contrSle sont adapts k 
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extraire de ladite premiere r6ponse une inforaiation contenue dans ledit enregistrement 
et a la fonnatesr pom la transmettre au dit terminal via lesdits moyens de 
communication. 

5 5) Syst^me selon la revendication 3, caracterise en ce que, la premiere base de 

donnees 6tant hebergee par ledit serveur LDAP, les moyens de contrdle sont adaptfe h 
Kctraire de ladite premiere reponse I'adxesse du serveur LDAP. 

6) SystSme selon la revendication 5, caract6ris6 en ce que, lesdits moyens de 
10 gestion de protocole sont adapts h transmettre une requfite en consultation selon le 

protocole LDAP (LDAP Search) audit serveur LDAP et h recevoir de celui-ci une 
seconde r6ponse. 

7) Systfeme selon la revendication 6, caract6ris6 en ce que les moyens ^ 
15 contr61e sont adaptds h extraire de ladite seconde r^onse une information contenue 

dans ledit enregistrement et 4 la formater pour la transmettre au dit terminal via lesdits 
moyens de communication. 

8) Systfeme selon la revendication 4, caract6ris6 en ce que, les moyens de 
20 controle ayant d^tentnin^ une operation de raise k jour, les moyens de gestion de 

protocole sont adapt^s, sur instruction desdits moyens de contrdle, i transmettre une 
requSte &i mise a jour selon le protocole DNS (DNS Update). 

9) Systeme selon la revendication 8, caract^ris^ en ce que les moyens de gestion 
25 de protocole sont adapts h recevoir une reponse de confirmation/infirmation de mise 

a jour du serveur DNS et les moyens de contrdle sont ad^t6s i formater cette reponse 
de confinnation/infirmation avant d'en ordonner la transmission au dit t«minal via 
lesdits moyens de communication . 

30 10) Systdme selon la revindication 7, les moyens de contrSle ayant ddtermin6 

une operation de mise d. jour, les moyens de gestion de protocole sont adaptfe, sur 
instruction desdits moyens de contrdle, k transmettre une requite en mise a jour selon 
le protocole LDAP (LDAP Modify). 
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11) Systeme selon la revendication 10, caracterise en ce que les moyens de 
gestion de protocole sont adaptes a recevoir une r6ponse de confirmation/infirmation 
de imse k jour du serveur LDAP et les moyens de controle sont adaptes k fonnater 

.4r^ ne>. A. or^nfirmation/infimiation avant d^en ordonner la tr ansmission au dit 
5 taminal via lesdits moyens de communication . 

12) Systeme selon la revendication 2, caracterise en ce que les moyens de 
controle sont adaptes a stoclcer dans la seconde base de donn^ un proffl de 
configuration transmis via lesdits moyens de communication, ledit proffl 6tant 

10 constitue d'une ou plusieurs demandes de modification programmee, chaque demande 
de modification programme 6tant associ^ a au moins une plage temporelle et/ou une 
zone g6ographique. 

13) Systdme selon la revendication 12, caracteris6 en ce que lesdits moyens de 
15 contrdle comprennent un automate de configuration (74) adapts a scniter ladite 

seconde base de donnfes et k tester si une mesuie de ten^>s ^partient a ladite plage 
et/ou une localisation du teraunal appartient k ladite zone, et en cas de r6sultat positi^ 
k extraire la demande de modification programmee associ^e et k tiansmettre aux dits 
moyens de gestion de protocole une demande de consultation de la premiere base de 
20 donn^es. 

14) Systdme selon la revendication 13, caracterise en ce que lesdits moyens de 
gestion de protocole sont adaptes k formuler ladite requSte en consultation selon le 
protocole DNS (DNS Query) ou LDAP (LDAP Search) et k recevoir, du serveur 

25 h6bergeant la base de donn6es, le contenu dudit enregistrement 

15) Systeme selon la revendication 14. caracterise en ce que si le contenu dudit 
enregistrement n'est pas conforme a ladite demande de modification programmee, 
lesdits moyens de contrdle determinent une operation k eflfectuer sur ledit 

30 enregistrement pour le rendre conforme k ladite demande de modification 
programmee et lesdits moyens de gestion de protocole formulent, en fonction de ladite 
operation, une lequSte de mise k jour de ladite prendfere base de donnSes selon le 
protocole DNS ou LDAP et I'acheminent vers le serveur hebergeant ladite premiere 
base de donnees. 
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16) Systdme selon la revendication 15, caracteris^ en ce que lesdfts moyens de 
gestion de protocole sont adaptfe h recevoir une reponse de coixfiramtion/infirmation 
de mise k jour du serveur hebergeant la premiere base de domees et que les moyens 

5 de controle sont adapt6s a detecter ladite reponse de confirmatioii/mfirniation et a la 
stocker sous forme d'historique dans la seconde base de donn6es. 

17) Syst^me selon la revendication 16, caracterise en ce que lesdits moyens de 
controle sont adaptes k recevoir xme demande de lecture dudit historique, et apres 

10 authentification de T^metteur de ladite demande par lesdits moyens d'authentification, 
a lui transmettre le contenu dudit historique via lesdits moyens de communicatioa 

18) Syst&nae selon la revendication 17, caracteris6 en ce que lesdits moyens de 
gestion de protocole sont adaptes a recevoir une reponse de confirmatioii/infirmation 

15 de mise k jour du serveur h6bergeant la premiere base de donn^es et que les moyens 
de contrdle sont adaptes a detecter ladite r6ponse de conj&rnmtion/infaination et k 
transmettre un conapte-rendu de ladite operation k un terminal de notification. 

19) Systfeme selon Tune des revendications pr^cedentes, caract^rLse en ce que 
20 lesdits moyens de gestion de protocole sont adaptes a utiliser im protocole DNS de 

type securise (DNSSec). 

20) Systeme selon Time des revendications pr^cedentes, caracteris6 en ce qu'il 
comprend une interface RTC et/ou KNIS (51) connectant lesdits moyens de 

25 communication au r6seau RTC/ KNIS, 

21) Systfeme selon la revendication 20, caracteris6 en ce que lesdits moyens de 
commimication comprennent un module de synthese vocale (55) ou im module de 
reproduction de fichiers vocaux (56) permettant de g6nerer im menu vocal, de 

30 reproduire une ou des informations dudit enregistrement sous forme vocale, ainsi 
qu'tin module de reconnaissance de signaux DTMF (54) et/ou un module de 
reconnaissance vocale permettant de reconn^e un choix dans ledit menu vocal. 
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22) Systdme selon la revendication 20, caracteris6 en ce que lesdits moyens de 
communication comprennent un serveur videotex (57) permettant de g6n6rer un menu, 
de saisir une demande de consultation ou de modification dudit enregistrement et de 
...^.oduire une on des informations dudit enregistrement ou une r^ponse de 



confirmationrmfirmatioti de mise ^ jour sous forme de sequences videotex. 

23) Systeme selon la revendication 20, caracteris6 en ce que lesdits moyens de 
communication compremient un module d'6mission/r6ception de messages SMS (58) 
permettant de recevoir sous fonne de message une demande en consultation ou de 
10 modification dudit enregistrement et de transmettre sous forme de message une ou des 
informations dudit enregistrement ou une r^onse de confinnationAinfirmation de mise 
ajomr. 

24) Systeme selon la revendication 20 conq)ortaut une interfece RNIS (51), 
15 caract6ris6 «x ce que les moyens de communication con^iennent un module 

d'emission/ reception (53) d'infonnation usag^ k usager lUU, permettant de recevoir 
sous fonne d'une dite information TUU, une demande en consultation ou de 
modification dudit enregistrement et de transmettre sous fonne d'une dite mfonnation 
lUU une ou des infonnations dudit rairegistrement ou une r6ponse de 
20 confirmation/infinnation de mise i jour. 

25) Systeme selon la revendication 20, caracteris6 en ce qu'U comprend un 
module fex (59) pennettant de transmettre une ou des infonnations dudit 
enregistrement ou une r^ponse de confinnation/infinnation de mise ^ jour. 

26) Systeme selon Tune des revendications 1 a 19, caract6ris6 en ce qu'il 
comprend une interface IP (60). 

27) Systeme selon la revendication 26, caract6ris6 en ce que les moyens de 
communication comprennent un serveur Web adapte h transmettre un fonnulaire 
d'authentification, un fonnulaire de sai^e d'une demande de consultation ou de 
modification dudit enregistrement, de pr&enter une ou des infonnations dudit 
enregistrement ou une r^ponse de confinnationTinfinnation de mise a jour sous fonne 
de pages Web. 
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28) Systeme selon la revendication 26, caracterise en ce que les moyens de 
communication comprennent un serveur SMTP adapte a recevoir sous forme d'emails 
une demande de consultation ou de modification dudit enregistrement et de 

5 transmettre sous forme d' emails ime ou des informations dudit enregistrement ou une 
reponse de confinnation/iiifinnation de mise a jour, 

29) Systeme selon Tune des revendications pr6c6dentes, caract6ris6 en ce que 
les moyens de contr&le sont adaptes k determiner ledit nom de domame k partir d'un 

1 0 identtfiant d^abonn& 

30) Systdme selon la revendication 29, caracterise ea ce que ledit identifiant 
d'aboxme est le num^ro teiephonique E J 64 dudit abonn6« 

15 31) SystSme selon la revendication 29 ou 30, caracterise en ce que lesdits 

moyens de controle sont adaptes k extraire des informations et k determiner en 
fonction de ladite demande une operation k efifectuer sur im enregistrement de 
ressource de type NAPTR. 

20 32) Systdme selon I'une des revendications pr6cedentes caracterise eii; ce que 

lesdits moyens de contrdle sont adaptes k extraire des informations et h determiner en. 
fonction de ladite demande une operation k effectuer sur un ou plusieurs 
enregistrements de ressource de type A, NS, MD, MF, CNAME, SOA» MB, MG, MR, 
NULL, WKS, PTR, HINFO, MINFO,MX, TXT. 
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